No one answered my original email to create a design document, so I will do it anyways and see what happens, if anything maybe I get a better understanding and follow your advice to create my own patch since neither existing patch looks "fine" to me (and it appears to core developers as well) in its implementation. I don't particularly like the "inner prefixing" that the namespace patch performs, and while the module concept looks nice, it uses the zend_class_entry structs to modularize which doesn't sit well with me either and obviously had a few problems when it was first tried in the early 5.0 development.
Bob Silva > -----Original Message----- > From: Marcus Boerger [mailto:[EMAIL PROTECTED] > Sent: Monday, November 28, 2005 2:43 PM > To: Bob Silva > Cc: 'Jessie Hernandez'; internals@lists.php.net > Subject: Re: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out > there) > > Hello Bob, > > there is no technical reason against this. Bbtw there is no technical > reason against \ either. Infact \ is the only seperator symbol that > doesn't > come along with technical problems that leed to conflicts or restrictions > or > confusion or more of those. Apart from that last time we decided against > those because we had namspaces as special classes. Indeed our namspaces > were > static classes. Introducing private nad protected now on classes would > contradict the is_a approach. No suppose you have a namespace n with two > classes a and b where a is private. Now in your code you derive class b as > your new class c - now BOOM. > > best regards > marcus > > Monday, November 28, 2005, 11:01:12 PM, you wrote: > > > Can someone explain why you wouldn't want private and/or protected > classes > > within a namespace? I imagine it would be due to problems with > > implementation... thanks for an explanation. > > > Bob > > > -----Original Message----- > > From: Marcus Boerger [mailto:[EMAIL PROTECTED] > > Sent: Monday, November 28, 2005 12:26 PM > > To: Jessie Hernandez > > Cc: internals@lists.php.net > > Subject: Re: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out > > there) > > > Hello Jessie, > > > yes and no. During 5.0 development i had private and protected > inheritance > > already and we voted against them. So i think we would vote against > private > > classes in namespaces as well. > > > regards > > marcus > > > Monday, November 28, 2005, 9:19:32 PM, you wrote: > > >> Marcus, > > >> In my patch, you can define the class as "private" inside the > namespace, > > so > >> it could only be derived by classes inside the same namespace > >> (using/instantiating outside will trigger an error). This might solve > your > >> problem. > > > >> Regards, > > >> Jessie > > > >> "Marcus Boerger" <[EMAIL PROTECTED]> wrote in message > >> news:[EMAIL PROTECTED] > >>> Hello Stanislav, > >>> > >>> Monday, November 28, 2005, 9:10:55 PM, you wrote: > >>> > >>> MB>>>'Config' or 'Setup' or alike then. But if i'd do that i'd be > missing > >>> MB>>>features like static classes.... the php workaround would be > >> 'abstract > >>> MB>>>final class'. Only: > >>> > >>> > Why should it be final? Extending it won't do any problem AFAIU. > >>> > >>> If it is not final you could derive the config class and then > instanciate > >>> it. Static classes which nicely fit into configuration stuff can never > be > >>> instanciated. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
