[PHP-DEV] Class visibility in namespaces
Hi,
I'm hoping I don't cause yet another flame war about the n-word ;)
I was wondering if namespaces are going to support class visibility, and
if no, would it be worth considering adding that feature? What I mean
exacty is:
In namespace Foo:
public class Foo { }
protected class Bar { }
- Bar can be instantiated from any class (or function) within the
namespace Foo
Outside of namespace Foo:
- class Foo in namespace Foo can be instantiated
- class Bar in namespace Foo can't be instantiated
Ron
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] UltraSimple Namespace Solution
Nathan Rixham wrote: thus: //this is always the function two in namespace one::step one::step::two(); //this is always the method two of class step in namespace one one::Step::two(); thoughts, opinions, reasons why it wouldn't work? Though: this will break a awful lot of existing code Opinion: bad idea Ron regards, nathan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
Greg Beaver wrote: Hi, http://wiki.php.net/rfc/namespaceissues Read it and discuss. Let's be clear people: the technical problems in namespaces are limited and solvable. The problems in the political environment surrounding them may not be. Wouldn't politics be a stupid-ass reason to remove namespaces? Greg +1 on #3 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespaces and alpha3
Lester Caine wrote: What would be the advantage of wrapping legacy functions in a namespace over wrapping them into a class as static functions? THAT is probably why I am asking the question? And may well be key to my understanding why converting non OO code into OO code in PHP is so problematic. When I was coding in CC++ more heavily libraries did not need to be objects and the 'namespace' just wrapped the code OR the code was built as an object. That is what I understand by a namespace, so perhaps I do not understand why leaving out functions and constants is acceptable :( I don't think there's any difference between moving non OO functions to a class and making the static and moving those to a namespace (in a suggested syntax it would be: Bar:::foo() for a namespace and Bar::foo() already for a class). Even more, I think there are advantages for moving a legacy app to a class because it allows you to make your global variables (like things in legacy apps) class members. Of course that's only an advantage if you agree that globals are evil... So my conclusion would be that leaving out functions and constants is acceptable because there's no advantage of having those in a namespace. Classes already provide everything you would possibly want from namespaces for functions and constants. Ron -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespaces and alpha3
Tony Bibbs wrote: This is what I've be fearing. First slated for 5.0. Then 5.3. Now 6.0. It appears there's consensus to rip it out which, in my prior post, I was all for if people felt it meant getting it right. Apparently that is the case. I guess my main question is what keeps this from being pushed yet again once 6.0 drops? From the community standpoint we keep hearing its coming, its coming but here we are still waiting. Again, I'm fine with the decision but I think others share similar concerns and will want to hear a commitment (dare I say promise) to adding namespaces to 6.0. --Tony - Original Message From: Stefan Walk [EMAIL PROTECTED] To: internals@lists.php.net Sent: Tuesday, October 14, 2008 7:46:58 AM Subject: Re: [PHP-DEV] namespaces and alpha3 On Tuesday 14 October 2008 14:10:50 Steph Fox wrote: I'm +1 on ripping out and leaving til 6.0. I don't think there is enough time between now and the 5.3.0 code freeze to make major changes to the language syntax. Major changes like ripping the feature that most people are looking forward to in 5.3 out? I'd really like to see namespace in 5.3. After reading most of the threads I'm still not real sure what the *real* problem is with the current implementation. It's down to stuff with constants and functions. IMO namespaces are very much an OO thing, meaning constants and functions should be in classes anyway. There's only a problem if you want there to be a problem. Foo::Bar::baz() is in class Bar in namespace Foo. Foo::Bar::BAZ is a constant in class Bar in namespace Foo. Ron -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] json_encode ignores protected/private class members
Stefan Walk wrote: That would be unclean. If it's implemented in some way, json_encode should look for the implementation of some interface (JSONEncodable or something) providing encoding/decoding methods (similar to __sleep/__wakeup). Looking at our current JSON implementations, such an interface would be very very welcome. If at all possible something like JSONDecodable would be great as well, for restoring class members from json. Ron -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
