From zeta-dev-return-144-apmail-incubator-zeta-dev-archive=incubator.apache.org@incubator.apache.org Sat Jul 31 14:20:47 2010 Return-Path: Delivered-To: apmail-incubator-zeta-dev-archive@minotaur.apache.org Received: (qmail 73327 invoked from network); 31 Jul 2010 14:20:47 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 31 Jul 2010 14:20:47 -0000 Received: (qmail 21035 invoked by uid 500); 31 Jul 2010 14:20:47 -0000 Delivered-To: apmail-incubator-zeta-dev-archive@incubator.apache.org Received: (qmail 20973 invoked by uid 500); 31 Jul 2010 14:20:46 -0000 Mailing-List: contact zeta-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: zeta-dev@incubator.apache.org Delivered-To: mailing list zeta-dev@incubator.apache.org Received: (qmail 20950 invoked by uid 99); 31 Jul 2010 14:20:45 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 31 Jul 2010 14:20:45 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [85.214.110.30] (HELO hartes-php.de) (85.214.110.30) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 31 Jul 2010 14:20:39 +0000 Received: (qmail 8637 invoked from network); 31 Jul 2010 14:20:18 -0000 Received: from dsbg-d9bb12fc.pool.mediaways.net (HELO ?192.168.0.250?) (tobias@schlitt.info@217.187.18.252) by hartes-php.de with ESMTPA; 31 Jul 2010 14:20:18 -0000 Message-ID: <4C543121.1070308@schlitt.info> Date: Sat, 31 Jul 2010 16:20:17 +0200 From: Tobias Schlitt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: zeta-dev@incubator.apache.org References: <4C4AC7B6.5000006@schlitt.info> <1f9eee05c863b46184af51331e0d3348.squirrel@srv11.sysproserver.de> <4C540AD0.8000505@schlitt.info> <4C541EF1.5090207@andreass.net> In-Reply-To: <4C541EF1.5090207@andreass.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Subject: Re: [zeta-dev] Re: Class prefix change, was: Re: [zeta-dev] Welcome Apache Zeta Components - SVN up and running :) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 07/31/2010 03:02 PM, Andreas Schamberger wrote: > creating a successful new brand zeta components in my opinion also > requires to change the prefix even if causes some migration pain. I don't see where the class prefix does much harm here. Where exactly do you see the problem? "Some migration pain" is what people are always annoyed for with new PHP releases where they did not realize a BC break before. BC breaks are a big nono from a business economical perspective. Especially if a project has few tests. >> On 07/31/2010 12:57 PM, Andreas Schamberger wrote: >>> 1) I'm not so happy with keeping the ezc prefix. As far as I recall it >>> wasn't really considered to change the class prefix to zeta. Ok the >>> reasoning is valid but wouldn't this big step of moving to Apache >>> justify >>> the change? If we don't change it now it'll maybe stay forever ... Using >>> the autoload files for a conversion script would be a save way to do the >>> conversion. >> we considered several ways for changing the class prefix. A fundamental >> requirement here is, that people must be able to migrate smoothly. BC >> has always been one of the major concerns of eZ Components and we want >> to keep it that way. > But it can also become a major annoyance when being obsessed with it ;) >> Script based migration is not fully possible, due to PHP's dynamic >> nature. For example, if you're using call_user_func() and friends, >> conversion is likely to fail. We could therefore not guarantee that >> migration to a new class prefix works flawlessly. > > I think the script based approach could be considered relatively safe. > The call_user_func problem is obvious but I don't see it as a blocker. > There are 3 major cases: > > 1) object method call > $object = 'ezcClassName'; > call_user_func( array( $object => 'method' ); What about building a class name dynamically, e.g. for some kind of dispatching, or transmitting it into a deeply nested object structure? call_user_func() is not used in cases as you show it here, but exactly for when you don't know the classname deterministically. > 2) static class function call > call_user_func( array( 'ezcClassName' => 'method' ); > 3) static class function call with variable > a) $className = 'ezcClassName'; > call_user_func( array( $className => 'method' ); > b) $className = 'ezc' . 'Class' . 'Name'; > call_user_func( array( $className => 'method' ); Same for these two cases. Nobody woul perform such a call, since the class name is known. > Is the only problematic case 3b), where the class name is constructed > completely dynamic worth not to change the prefix? Is it such a common > use case? Exactly this is the common case for uses of call_user_func() and friends, as well as simply doing $foo = new $class(); Migration is not possible on a pure script basis. There are people out there relying their business on the use of our library. Regards, Toby - -- Tobias Schlitt http://schlitt.info GPG Key: 0xC462BC14 Want to hire me? Need quality assurance? http://qafoo.com eZ Components are Zeta Components now! http://bit.ly/9S7zbn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxUMSAACgkQ5bO3TcRivBSIhgCdHG49+C3WfSfIwww0FnDjL0KI Y4UAoLBI+deK9KIh29GRZZCWxHMVijk0 =YlKU -----END PGP SIGNATURE-----