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
