Stanislav Malyshev wrote: > Hi! > >> The problem with that statement is that if it is used to ignore the >> other problems, then at some point it may be necessary to re-write all >> the new namespace code simply to allow additional features to be added! > > So? We rewrote pretty much every other part of PHP - engine, object > model, filesystem, etc. - and nobody died. Suddently with this > particular feature there's tremendous fear of commitment. But we aren't > going anywhere by sitting and talking about "what if". We get anywhere > only by releasing features and seeing what they do.
My point is that for this code: <?php Classname::Method(); ?> The proposal does not solve the name conflict. If no one rewrites their code to use Classname->Method(), then no one will be protected from the ambiguity. I am thinking of the case where a user adds a new feature to their existing code that uses a 3rd-party library with namespaced functions that accidentally conflict with the user's classes without their knowledge. As third-party libraries become easier to distribute (which both phar and pyrus plan to do), this will become more of an issue. Our experience with other changes forced upon existing code has shown that user inertia is high, and we can't expect to fix things simply by asking the users to rewrite their code unless PHP tells them to with E_STRICT or other warnings. Should I add this to the explanation or is it clear enough? Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
