Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:35625 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 48628 invoked by uid 1010); 19 Feb 2008 23:03:17 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 48613 invoked from network); 19 Feb 2008 23:03:17 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Feb 2008 23:03:17 -0000 Authentication-Results: pb1.pair.com header.from=stefan.marr.de@gmail.com; sender-id=pass; domainkeys=bad Authentication-Results: pb1.pair.com smtp.mail=stefan.marr.de@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.184.229 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: stefan.marr.de@gmail.com X-Host-Fingerprint: 64.233.184.229 wr-out-0506.google.com Linux 2.4/2.6 Received: from [64.233.184.229] ([64.233.184.229:39195] helo=wr-out-0506.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 10/8D-55225-4306BB74 for ; Tue, 19 Feb 2008 18:03:17 -0500 Received: by wr-out-0506.google.com with SMTP id c38so2330907wra.17 for ; Tue, 19 Feb 2008 15:03:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=Ctiq7PNPWfWBQioIZayzWxkHMXqJn6QlRxIHe1e3MSE=; b=q6M+Uiwp3FYZIm6xUFeChQyE8ghAvzPSYeg7Ae+5VpgxrREDEQQVov6+yELHWlJjBcrzF5MS9Qlx+rJAM3q09/JHYHFonBKtM0GeKoO7+kd4eY2SymCYpYpqm4r1M1Y+90mQGrt5CUsWF13G0ciasM3yyv+j9sOWE96efV9LDyI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=xe6M7G8zk1/MXNQr3JB99wXtX3ithFodeSx5pkp09oTG3J35Os55DUy4j/JPhc9E6XXp9QKbweHzPYYesUFuqKfw9qvr9FpJSqrpErpmUqwATdpNftitJVrSA+yuAmo5ORZpJF2UVM6bxnPPveCEVkqgA70P9mqcUX8AS8ezuxU= Received: by 10.143.161.3 with SMTP id n3mr5858270wfo.114.1203462193752; Tue, 19 Feb 2008 15:03:13 -0800 (PST) Received: by 10.142.141.2 with HTTP; Tue, 19 Feb 2008 15:03:13 -0800 (PST) Message-ID: <1e12984d0802191503u460bb76bgdcd428cb601a26b5@mail.gmail.com> Date: Wed, 20 Feb 2008 00:03:13 +0100 Sender: stefan.marr.de@gmail.com To: "Lars Strojny" Cc: internals@lists.php.net, "=?ISO-8859-1?Q?Marcus_B=F6rger?=" , "=?ISO-8859-1?Q?Johannes_Schl=FCter?=" , "Sebastian Bergmann" , "Alexandre Bergel" , "Falko Menge" , "Sara Golemon" , derick@php.net In-Reply-To: <1203461114.24580.45.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <001c01c87264$3c01b4e0$b4051ea0$@de> <1203461114.24580.45.camel@localhost> X-Google-Sender-Auth: b06d0277b7f4d325 Subject: Re: [PHP-DEV] RFC: Traits for PHP From: php@stefan-marr.de ("Stefan Marr") 2008/2/19, Lars Strojny : > Hi, > > Am Montag, den 18.02.2008, 20:27 +0100 schrieb php@stefan-marr.de: > [...] > > To underpin this relationship, it is possible to declare that a Trait > > implements an interface like this:: > > > > > interface IHello { > > public function sayHello(); > > } > > > > trait SayHello implements IHello { > > public function sayHello() { > > echo 'Hello World!'; > > } > > } > > > > class MyHelloWorld { > > use SayHello; > > } > > > > $o = new MyHelloWorld(); > > var_dump($o instanceof IHello); // bool(true) > > We have discussed that in IRC a bit and a lot of questions remain. The > most important issue to me how to handle interface implementations in > cases where methods from the interface implementing trait are renamed in > the trait consumer class. Well, it is aliasing, not renaming. Think only the exclusion of a method will break the interface, but since the interface is propagated to the class the class has to take care that it is implemented properly and an error will be raised if it is not implemented correctly at compile time. Let say I modify the example like this: class MyHelloWorld { use SayHello { !sayHello } } the compiler will give an error that sayHello is missing since MyHelloWorld states it is implementing IHello. > I would propose to not overcomplicate things here and I see no real > advantage in allowing traits to implement interfaces. I think also for > the sake of conceptual integrity separating interfaces clearly from > traits is a good idea: interfaces define structure while traits are > function buckets. A class may use traits, may implement interfaces and > may extend another class. This paradigm is pretty easy to explain to the > user. Yes it is definitely a conceptual problem to propagate interfaces, because the notation does not imply this behavior and you can not see the interfaces added by the trait. Therefore, I'm with you, interface propagation might be a point to not be included. Kind Regards Stefan