Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:35818 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 34208 invoked by uid 1010); 27 Feb 2008 14:38:41 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 34193 invoked from network); 27 Feb 2008 14:38:41 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Feb 2008 14:38:41 -0000 Authentication-Results: pb1.pair.com header.from=rquadling@googlemail.com; sender-id=pass; domainkeys=bad Authentication-Results: pb1.pair.com smtp.mail=rquadling@googlemail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 64.233.184.224 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: rquadling@googlemail.com X-Host-Fingerprint: 64.233.184.224 wr-out-0506.google.com Linux 2.4/2.6 Received: from [64.233.184.224] ([64.233.184.224:4437] helo=wr-out-0506.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 8D/01-23608-EE575C74 for ; Wed, 27 Feb 2008 09:38:40 -0500 Received: by wr-out-0506.google.com with SMTP id c38so4226912wra.17 for ; Wed, 27 Feb 2008 06:38:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=+7oFc15WDQiK69gKZZf2fbxqhgn/w7GoD3fZG2Ma/iM=; b=T8nTamJW21fjmZXiMHfyaQUwGwoGX3lusCFtZMx/I1ITeAff4rhTGedIzhFMDP6lPIjCy8E3ccd0KQYogvOnxr5Ben4v+NLbpwfa+nwIuIbF68HjagJFXRN3GmO82uFbSedMpTOKCDA9L64fl3MhmkSuiKpkR044448G8DGlxcQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=F3EihGcWPn4dvOVbUq4+65YC71nmSkfd7XRXpAj8OV3PAf6uGUZEIDzrqfUftm8BC9oNGnBwRp359S0SZmlEdLXaConcC5pGXJTgVBuOh7IoUWNifBcSPgUp/KxX0hZkelQR73HVeSq6BVq8NGCdPROo+lj1rKIMNnpjCr21uC0= Received: by 10.114.106.1 with SMTP id e1mr7445427wac.95.1204123112522; Wed, 27 Feb 2008 06:38:32 -0800 (PST) Received: by 10.114.209.15 with HTTP; Wed, 27 Feb 2008 06:38:32 -0800 (PST) Message-ID: <10845a340802270638t7a0a177yad0543d5065b3f64@mail.gmail.com> Date: Wed, 27 Feb 2008 14:38:32 +0000 Reply-To: RQuadling@GoogleMail.com To: php@stefan-marr.de Cc: "Internals Mailing List" In-Reply-To: <47C571A7.9030701@stefan-marr.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47C317F4.2080301@stefan-marr.de> <10845a340802251336l4ec51e2bg493f0bd8e4684264@mail.gmail.com> <47C571A7.9030701@stefan-marr.de> Subject: Re: [PHP-DEV] How to build a real Trait thing without exclusion and renaming From: rquadling@googlemail.com ("Richard Quadling") On 27/02/2008, Stefan Marr wrote: > Hi Richard, > > Richard Quadling schrieb: > > > Traits as namespaces would solve the issue of conflict in the class > > Talker (you would have to explicitly say which trait the method came > > from. > > Yes, this would solve the conflicts, but is this really handy? > Every explicit reference to a trait/class name has to be adjusted if the > name changes or if there are any incompatible changes in the hierarchies. > Explicit references by names is probably always a solution, but not the > best. The inventors of the trait idea tried to avoid it in favor to > avoid the fragility introduced by it. > > > > > > > I don't know if this can all be resolved at compile time. Surely the > > use of call_user_func() and others would impact somehow. > > > > If trait C requires trait D, then this may lead to longer namespaces - > > but from my understanding the purpose of namespaces is to resolve > > collisions, so it cannot be avoided when there are collisions. (Though > > my example doesn't collide - but that's not the point). > > > > I hope this makes some sense. > > It would be a possible way, but personally I would not like to go there. I can certainly understand your reluctance. It does make things look complicated. But my first reasoning for suggesting it is that we are have namespaces in PHP6 primarily to reduce the conflicts between built in classes and userland classes/libraries. By having an alternative aliasing mechanism for traits, we now have 2 mechanisms to learn, both of which resolve names in some way. (For: traits aren't namespaces, Against: Trait conflict resolution certainly looks like it could be solved with namespaces). Your primary argument against them of "has to be adjusted if the name changes" holds true with namespaces any way. In fact if method/class/interface/function X becomes method/class/interface/function Y, I have to change something anyway. So, this is the norm, not the exception. My second reasoning is that namespaces act as encapulation. They are still white-box. But encapsulated. So inside the trait all the methods can talk to each other quite happily (statically or otherwise). It just works and is based upon existing ideas (assuming we are in a PHP6). -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!"