-----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-----
