Re: [PHP-DEV] true namespaces, yet another point of view
On 29.09.2008, at 00:21, Gregory Beaver wrote: Lukas Kahwe Smith wrote: On 24.09.2008, at 01:17, Guilherme Blanco wrote: For those that do not understand very well the explanation of jvlad... He's suggesting to change the class struct to be an scope struct, and have a property that tells if it's a namespace or a class, and reuse the implementation of class which already works very well. The nested support is achieved afai understand through the Adjacency List algorithm... can you confirm this to me? or just leave the organization of things to classes (with long class names with a nice prefix to prevent collissions) and leave it to class_alias() (and equivalent features for functions .. also with the option of a compile time aliasing) to handle the aliasing. this removes the need for namespaces and use statements, while making it possible to make class/function names short (that are long for organizational and collision prevention reasons). Hi, This approach doesn't work because aliasing with class_alias() does not allow name conflicts: Well my point was .. Library code uses long names, glue code can alias. Of course sometimes the lines between what is library and glue code are hard to draw. Anyways, I guess we are close to a good solution for namespaces in 5.3 .. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] true namespaces, yet another point of view
For those that do not understand very well the explanation of jvlad...
He's suggesting to change the class struct to be an scope struct, and
have a property that tells if it's a namespace or a class, and reuse
the implementation of class which already works very well.
The nested support is achieved afai understand through the Adjacency
List algorithm... can you confirm this to me?
or just leave the organization of things to classes (with long class
names with a nice prefix to prevent collissions) and leave it to
class_alias() (and equivalent features for functions .. also with the
option of a compile time aliasing) to handle the aliasing.
this removes the need for namespaces and use statements, while making it
possible to make class/function names short (that are long for
organizational and collision prevention reasons).
Hi,
This approach doesn't work because aliasing with class_alias() does not
allow name conflicts:
?php
class foo {
function __construct(){echo 'hi',\n;}}
class_alias('foo', 'XMLReader');
$a = new XMLReader;
?
results in:
Warning: Cannot redeclare class XMLReader in
/home/cellog/workspace/php5/test.php on line 4
?php
class foo {
function __construct(){echo 'hi',\n;}}
use ::foo as XMLReader;
$a = new XMLReader;
?
results in:
hi
I'm sorry I don't see anything related to namespaces in the sample. It looks
like just a trick that allows to bypass restrictions imposed on
class_alias(). If you need to provide a clear way on creating your very own
XMLReader class in the global namespace, while the class with the same name
is already registered by an extension, why not to create
remove_class()/unregister_class() and/or replace_class() functions which
will legitimate class removal/overriding?
Still not sure if it's needed at all. With namespaces, you can create your
own little world inside your private namespace and have as many overrided
classes as you want. Why bother with global namespace?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] true namespaces, yet another point of view
Lukas Kahwe Smith wrote:
On 24.09.2008, at 01:17, Guilherme Blanco wrote:
For those that do not understand very well the explanation of jvlad...
He's suggesting to change the class struct to be an scope struct, and
have a property that tells if it's a namespace or a class, and reuse
the implementation of class which already works very well.
The nested support is achieved afai understand through the Adjacency
List algorithm... can you confirm this to me?
or just leave the organization of things to classes (with long class
names with a nice prefix to prevent collissions) and leave it to
class_alias() (and equivalent features for functions .. also with the
option of a compile time aliasing) to handle the aliasing.
this removes the need for namespaces and use statements, while making it
possible to make class/function names short (that are long for
organizational and collision prevention reasons).
Hi,
This approach doesn't work because aliasing with class_alias() does not
allow name conflicts:
?php
class foo {
function __construct(){echo 'hi',\n;}}
class_alias('foo', 'XMLReader');
$a = new XMLReader;
?
results in:
Warning: Cannot redeclare class XMLReader in
/home/cellog/workspace/php5/test.php on line 4
whereas:
?php
class foo {
function __construct(){echo 'hi',\n;}}
use ::foo as XMLReader;
$a = new XMLReader;
?
results in:
hi
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] true namespaces, yet another point of view
On 24.09.2008, at 01:17, Guilherme Blanco wrote: For those that do not understand very well the explanation of jvlad... He's suggesting to change the class struct to be an scope struct, and have a property that tells if it's a namespace or a class, and reuse the implementation of class which already works very well. The nested support is achieved afai understand through the Adjacency List algorithm... can you confirm this to me? or just leave the organization of things to classes (with long class names with a nice prefix to prevent collissions) and leave it to class_alias() (and equivalent features for functions .. also with the option of a compile time aliasing) to handle the aliasing. this removes the need for namespaces and use statements, while making it possible to make class/function names short (that are long for organizational and collision prevention reasons). regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] true namespaces, yet another point of view
I share your thoughts and yes namespaces are needed and wanted, but what's implemented at the moment is quite far from what I'd call a namespace. I need and want to see there all language entities including variables, constants, classes, interfaces, and functions. Want to see them all supported by namespaces or nothing. -JV I disagree here...it is both wanted and and needed. This feature has been promised to the community for quite some time now and I'd simply remind you you do have the option of *not* using namespaces if you don't want too. If you like REALLY_LONG_CLASS_NAMES that's still perfectly valid. Don't like it, don't use it but I think working through the remaining issues and getting it out is important. Making right decision on the approach is important too and from an outsiders point of view a lot of progress has been made and it now seems very, very close to being a reality. Ditching it should be the last thing considered. I can't say it enough, if you don't like where the namespace implementation ends up you can simply decide not to use it. --Tony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] true namespaces, yet another point of view
I completely agree with jvlad's thoughts - for me namespace is ability to
separate two different libraries from each other so that they don't
conflict. I don't need namespaces just to write my own application using
them to be cool, and I probably would never use a namespace for small or
middle size application, but what I will surely do - namespace libraries
witch I will use in my application, so that I don't have to use prefixes for
my application functions and classes.
AndIMHO, I _really_ _don't_ _want_ to remember those complicated rules for
name resolution, importing namespaces. There is category of developers,
witch will make a real mess of this. As I personally see namespaces:
index.php
?php
require_once('application.php');
namespace Zend {
require_once('zendframework.php');
}
namespace PDF {
require_once('tcpdf.php');
}
$loader = new Zend::ZendLoader();
$db = new Zend::ZendDB();
$pdf = new PDF::TCPDF();
$application = new Application();
$application-addHandler('loader', $loader);
$application-addHandler('db', $db);
$application-addHandler('pdf', $pdf);
$application-run();
$application-quit();
?
Of course that isn't a good example, because Zend framework always has a
class prefix Zend, but they surely can use a namespace and remove that
Zend in front of classes.
And I don't see any point in use NamespaceName as OtherName - I open a
project, there is namespace Foo used for libraries. Then I open some modules
- there is Bar::get() in the code. What will I look for? Namespace Bar,
especialy when many namespaces are used in application. imporing foo as bar
is quite confusing. Yes, we programmers can handle such things, we can learn
from our mistakes, but that's not the reason to make us masochist! I'm
fed-up with teaching people all the time how to properly code in PHP or
clean the code after such people. Really, sometimes PHP core developers
should say to comunity f*k you, we will do that the proper way and just
do. People are happy with Java, .NET and so on and nobody is complaining
that they can't import namespace under other name than original (maybe in
some languages you can do that, but I don't code much in other languages, so
I can't say that for sure). This is called standarts - everybody knows
that name Foo always means Foo if Foo package is used in application,
and that nobody can import it as Blah - they will have to change the
namespace in package itself and that's so stupid , that nobody will do that
(well if they do - don't mess with such people at all).
Re: [PHP-DEV] true namespaces, yet another point of view
Arvids Godjuks a écrit : Of course that isn't a good example, because Zend framework always has a class prefix Zend, but they surely can use a namespace and remove that Zend in front of classes. They are a lot of case where you want to use this syntax. The most common is when you have a depth namespace like a russian puppy : namespace org::w3::xhtml::strict as x ; The other reason is to use it for testing purposes, when you develop a new engine, that share the same API with the previous : // namespace org::w3::xml as xml ; namespace com::lupusmic::xml as xml ; But maybe it isn't a good use... :D Namespaces can be a usefull tool, but if wouldn't, don't use. And if it becomes mandatory, fork your own PHP version :D -- Mickaël Wolff aka Lupus Michaelis http://lupusmic.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] true namespaces, yet another point of view
Tony Bibbs wrote: I disagree here...it is both wanted and and needed. This feature has been promised to the community for quite some time now and I'd simply remind you you do have the option of *not* using namespaces if you don't want too. If you like REALLY_LONG_CLASS_NAMES that's still perfectly valid. Don't like it, don't use it but I think working through the remaining issues and getting it out is important. Making right decision on the approach is important too and from an outsiders point of view a lot of progress has been made and it now seems very, very close to being a reality. Ditching it should be the last thing considered. I can't say it enough, if you don't like where the namespace implementation ends up you can simply decide not to use it. --Tony As far as I know, that argument doesn't really fly here, since you might not use it, but in a large PHP project, someone in your team will. If you don't like it, don't use it doesn't hold since you still have to understand, and possibly modify, your teammate's code. A similar point was raised, IIRC, for the [1,2] short-array notation. This is particularly important because large codebases, usually with several people touching the code, are the primary target for namespaces, as opposed to short one-person form-processing scripts,. - Federico -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] true namespaces, yet another point of view
Federico Lebron wrote: Tony Bibbs wrote: I disagree here...it is both wanted and and needed. This feature has been promised to the community for quite some time now and I'd simply remind you you do have the option of *not* using namespaces if you don't want too. If you like REALLY_LONG_CLASS_NAMES that's still perfectly valid. Don't like it, don't use it but I think working through the remaining issues and getting it out is important. Making right decision on the approach is important too and from an outsiders point of view a lot of progress has been made and it now seems very, very close to being a reality. Ditching it should be the last thing considered. I can't say it enough, if you don't like where the namespace implementation ends up you can simply decide not to use it. --Tony As far as I know, that argument doesn't really fly here, since you might not use it, but in a large PHP project, someone in your team will. If you don't like it, don't use it doesn't hold since you still have to understand, and possibly modify, your teammate's code. A similar point was raised, IIRC, for the [1,2] short-array notation. This is particularly important because large codebases, usually with several people touching the code, are the primary target for namespaces, as opposed to short one-person form-processing scripts,. In addition one of the main reasons FOR namespace is to make libraries easier to manage, so if our own code does not use them it's likely that some library we select will - at some point. Hence my comments previously about having to take more care keeping things like namespace under control when deploying applications which may not have 5.3 available to run on. BC up to now has been relatively easy to maintain, but I have a feeling that 5.3 SHOULD be a major version number change so that we can maintain PHP5 compatibility easier? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] true namespaces, yet another point of view
Guilherme Blanco [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] For those that do not understand very well the explanation of jvlad... He's suggesting to change the class struct to be an scope struct, and have a property that tells if it's a namespace or a class, and reuse the implementation of class which already works very well. The nested support is achieved afai understand through the Adjacency List algorithm... can you confirm this to me? Just trying to be more clear to those that do not understand... if my words are greek now GIYF (Google Is Your Friend). Yep. Thanks Guilherme for such a short explanation. (sorry my english is quite poor and not always clear enough) Namespaces create ambiguity with classes in php (which is a dynamic language btw) just because their natures are very close. Beside the other great things, class is intended to isolate its methods and properties, or group them together. Namespace is mostly for the same purposes. It should isolate classes as well as all other user-land entities or group them together. From the end-user perspectives, in most cases it does not really matter if a particular value is stored as a static property of a class or as a global variable in a namespace. Same goes for the static method of a class vs function in the namespace. What's important is to know the scope name. If user uses a variable myentity::$var, it's safficient to lookup for myentity sub-scope in the current scope, then lookup for $var in the found (or just created) sub-scope. You see, it's not always needed to distinguish classes vs namespaces. In some cases the namespace can be resolved in the compile-time. For example if the namespace is already defined, so it's known to be namespace and therefore compiler should be smart enough to make early binding. For the cases when namespace is referenced in the script beforehand, so it's not known whether it is a namespace or a class, it can be resolved with late-binding, using absolutely the same technique as php uses for for resolving the classes. I'm sure this is an efficient way of implementing namespaces in php and with this implementation they will be very useful. jv -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] true namespaces, yet another point of view
Steph Fox [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] For those that do not understand very well the explanation of jvlad... Guileherme, you are missing the point. We'd all like to see PHP 5.3.0 out there. It has a lot to offer, but namespace support is very obviously problematic. That's it, that's all. - Steph Steph, Maybe I'm just missing the idea... to me it looks an attempt to advertize something that does not even exist. Do you think semi-working namespaces with limited support, that does not go beyound classes, will be greatly appreciated by php developers? What if anything can be solved or achieved with namespaces like offered in 5.3alpha? -jv -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] true namespaces, yet another point of view
Hello all,
May I suggest something in this area?
I hope it will resolve some problems related to namespaces and classes
ambiguity.
Let's first take a look at the classes.
In-general they represent two things: scope and data.
Scope is a thing that can't be changed without compiler efforts and contains
methods and constants. We access these things using :: separator.
2nd thing that I called data obviously contains class instance data that we
know under property name. We can change data during runtime and we do it
using executor. To access data we normally use - separator. At this point
somebody may want to point me out to the methods (the scope!) accessed
with - too. That's correct. But in this case we always mean $this or
$variable that points to the Data, where executor will find pointer to the
scope and will access it internally.
From this perspective, namespace is nothing more but another layer of
scopes. Indeed, it's supposed to contain all things like classes, functions,
and even variables. If we make namespaces as power as this, they will be
useful in complicated situations when for example you need to work with a
3rd party framework that is full of classes, functions, and global variables
with _the_same_ names as the ones you use in your own project. So you need a
way to _isolate_ the framework and you need to do it _without_ any
modifications in its code or you will have maintain your own changes in the
foreign code each time the code is changed. With appropriately powerful
namespaces, its just matter of moving all the framework objects (I mean
classes, defines, functions, and global variables) into namespace. It comes
with its own namespaces? Not a problem (see below).
I suggest to remove class table and introduce scope table. This table will
contain classes and namespaces.
Technically speaking, with this approach namespace may contain other
namespaces, classes, variables, defines, and functions. To access scope's
item you still use :: separator. It's not that hard to access items at any
level without even knowing you access class's scope or namespace's. It does
not really matter! You only need to know names of the scopes and their
relationship.
There is always current scope, which is global or noname namespace by
default. It's created before any other items such as embedded functions or
classes are created. If you have thing1::thing2 in your code, executor
should first lookup current scope for thing1 and if not found, lookup in the
global namespace (unless current is global). You see, it does not really
matter if thing1 is a class or namespace. It's just a scope name to lookup
for and once namespaces and classes are all in one hash, it's quite trivial
to do.
Include, require and their _once brothers, should include the file and
make all its objects (like classes, functions, global variables) to be
created in the current namespace. So the isolation will be achieved easily,
you simply put include into a namespace and all the rest, including nested
includes, will put all thing into the namespace.
namespace isolated_space {
include 3rdpartyframework/library.inc;
}
There is one more difference between namespaces and classes. You can span a
namespace across multiple files and have multiple chunks of the same
namespace in one.
With include sample above, to access functions or classes, we'll use
either way:
1. reopen namespace and make call from it:
namespace isolated_space {
afuntioncall();
}
2. specify the namespace explicitly:
isolated_space::afunctioncall();
In both cases, current namespace will be swithched to isolated_space and all
things accessed by afunctioncall() will be looked up for in this namespace
first.
Think about namespaces like directories in the filesystem. You can specify
relative and absolute path. All other items like files, symlinks, devices,
etc have to exist in directories.
-jv
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] true namespaces, yet another point of view
This one time, at band camp, jvlad [EMAIL PROTECTED] wrote: May I suggest something in this area? May I suggest something also.. Lets just let namespaces die and let it become a repressed memory as it seems it is more trouble that it is worth. Seriously. For 10+ years we have got on just fine without them, and the amount of work to get a second-best implementation that nobody agrees on hardly seems benificial. The gains of namespaces are minimal at best, because a few cannot be bothered with some simple prefixing. PHP 5.3 release is looming, and there is STILL conflict about implementation. The current approach is a long way from what was thought of as namespace support and it seems nobody is completely happy with any model that has been put forward. The current implementation is nothing but a series of comprimses, each one taking away a little of the functionality that was first envisaged. Lets just let it die. It is un-needed, un-wanted by many, and the end result seems to be less that optimal, or even a true implementation of namespaces. Kevin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] true namespaces, yet another point of view
I disagree here...it is both wanted and and needed. This feature has been promised to the community for quite some time now and I'd simply remind you you do have the option of *not* using namespaces if you don't want too. If you like REALLY_LONG_CLASS_NAMES that's still perfectly valid. Don't like it, don't use it but I think working through the remaining issues and getting it out is important. Making right decision on the approach is important too and from an outsiders point of view a lot of progress has been made and it now seems very, very close to being a reality. Ditching it should be the last thing considered. I can't say it enough, if you don't like where the namespace implementation ends up you can simply decide not to use it. --Tony - Original Message From: Kevin Waterson [EMAIL PROTECTED] To: internals@lists.php.net Sent: Tuesday, September 23, 2008 3:57:41 PM Subject: Re: [PHP-DEV] true namespaces, yet another point of view This one time, at band camp, jvlad [EMAIL PROTECTED] wrote: May I suggest something in this area? May I suggest something also.. Lets just let namespaces die and let it become a repressed memory as it seems it is more trouble that it is worth. Seriously. For 10+ years we have got on just fine without them, and the amount of work to get a second-best implementation that nobody agrees on hardly seems benificial. The gains of namespaces are minimal at best, because a few cannot be bothered with some simple prefixing. PHP 5.3 release is looming, and there is STILL conflict about implementation. The current approach is a long way from what was thought of as namespace support and it seems nobody is completely happy with any model that has been put forward. The current implementation is nothing but a series of comprimses, each one taking away a little of the functionality that was first envisaged. Lets just let it die. It is un-needed, un-wanted by many, and the end result seems to be less that optimal, or even a true implementation of namespaces. Kevin -- 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
Re: [PHP-DEV] true namespaces, yet another point of view
[EMAIL PROTECTED]: nothing of technical importance in this email, but it might make you feel better :-) ... even Stas!]] Kevin Waterson schreef: This one time, at band camp, jvlad [EMAIL PROTECTED] wrote: everything that jvlad wrote was way too vague for me to understand so I couldn't possibly comment on it. May I suggest something in this area? May I suggest something also.. Lets just let namespaces die and let it become a repressed memory as it seems it is more trouble that it is worth. Seriously. why does the ammount of trouble other people take upon themselves matter to you? ... and repressing memory is very bad advice (but that's rather esoteric). For 10+ years we have got on just fine without them, and the amount of work to get a second-best implementation that nobody agrees on hardly seems benificial. The gains of namespaces are minimal at best, because a few cannot be bothered with some simple prefixing. the gains are in the eye of the beholder, beyond the issue of symbol name collision avoidance there is big a real issue with very_very_very_very_very_very_very_very_looong_symbol_names ... it's a proven fact it becomes increasingly more difficult to grok lines of code as they increase in length ... namespaces offer a mechanism to mitigate overly long lines (at the cost of some obsfucation). you may decide the gains are minimal and not worth pursuing personally, but plenty of others feel the exact opposite. I'm personally a little ambivelent regard to inhouse code but I do envisage that libs like PEAR and ZF will become much more appealing when they take on namespaces, as such I care about whatever it [namespaces] becomes being 'good' .. because either way, sooner or later, I will be confronted with using them even if I don't use them in code I write myself. (my stance makes sense to me but It's likely I'm not expressing it very well!) PHP 5.3 release is looming, and there is STILL conflict about implementation. 1. conflict is everywhere, even outside of the world of php functionality implementations. 2. that 5.3 is 'looming' has surely not escaped the RMs 3. shouldn't 5.3 be release when it's ready rather because people expect it to be? The current approach is a long way from what was thought of as namespace support and it seems nobody is completely happy with any model that has been put forward. what exactly was thought of as namespace support? whatever it is exactly it is apparent that's it's wide open to mis-interpretation ... this is something to be tackled with documentation. I don't think the 'model' has been under attack, rather a number of ambiguity issues which were not fully foreseen ... issues which I might add are due in no small part to the 10+ years of baggage php has collected. it's easy to throw out the word 'namespaces' and assume everyone is on the exact same page ... it's rather harder to actually build something people are willing to call 'namespaces' ... the fact that it is hard and that the discussions have been long and difficult do not of themselves mean the effort and the impending result are not worthwhile. The current implementation is nothing but a series of comprimses, actually there has been very little comprise, that's one of the things the lead developer has been taking lots of flak for. each one taking away a little of the functionality that was first envisaged. the only thing that has been proposed to be taken away is functions and constants ... both of which can be incorporated at a later date (without the stress of release deadlines and having to deal with additional BC issues, imho), I personally think a phased introduction of namespacing functionality is not a bad thing, granted getting everything in one go would be nicer but at the end of the day you can't shoot yourself in the foot with a gun you don't have. the other major issue revolved around name resolution order upon which consensus has been reached in fact AFAICT (I've read everything that's been written AFAIK). Lets just let it die. It is un-needed, un-wanted by many, and the end result seems to be less that optimal, or even a true implementation of namespaces. I would offer that bandying about subjective opinions as to what is wanted, what is true, etc, etc as being objective fact is one of the things that needs to die more than anything else. php counts it's user's in the 100,000's if not 1,000,000's ... I'd hazard to say that it's nigh on impossible to get accurate stats regarding namespace support. rgds, Jochem -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] true namespaces, yet another point of view
Lets just let it die. It is un-needed, un-wanted by many, and the end result seems to be less that optimal, or even a true implementation of namespaces. Oddly enough, I agree with Kevin with my heart and soul. But then I hear the howls of outrage from the Other Side, who campaigned without ruth to get namespaces into PHP in the first place. Would someone with authority (Andi? Derick?) like to give an overview of the pros, cons and issues at this point? It's quite difficult to follow all these tiny, endless myco-esque threads, and I share Greg's allergy to wikis for the simple reason that the model is similar. Each item sparks another. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] true namespaces, yet another point of view
For those that do not understand very well the explanation of jvlad... He's suggesting to change the class struct to be an scope struct, and have a property that tells if it's a namespace or a class, and reuse the implementation of class which already works very well. The nested support is achieved afai understand through the Adjacency List algorithm... can you confirm this to me? Just trying to be more clear to those that do not understand... if my words are greek now GIYF (Google Is Your Friend). Cheers, On Tue, Sep 23, 2008 at 8:10 PM, Steph Fox [EMAIL PROTECTED] wrote: Lets just let it die. It is un-needed, un-wanted by many, and the end result seems to be less that optimal, or even a true implementation of namespaces. Oddly enough, I agree with Kevin with my heart and soul. But then I hear the howls of outrage from the Other Side, who campaigned without ruth to get namespaces into PHP in the first place. Would someone with authority (Andi? Derick?) like to give an overview of the pros, cons and issues at this point? It's quite difficult to follow all these tiny, endless myco-esque threads, and I share Greg's allergy to wikis for the simple reason that the model is similar. Each item sparks another. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9166-6902 MSN: [EMAIL PROTECTED] URL: http://blog.bisna.com Rio de Janeiro - RJ/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] true namespaces, yet another point of view
For those that do not understand very well the explanation of jvlad... Guileherme, you are missing the point. We'd all like to see PHP 5.3.0 out there. It has a lot to offer, but namespace support is very obviously problematic. That's it, that's all. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] true namespaces, yet another point of view
Steph... I think you should not tell me this... =) I already know it and heard (like you) 5,451,741,709,125 times. Cya, On Tue, Sep 23, 2008 at 8:31 PM, Steph Fox [EMAIL PROTECTED] wrote: For those that do not understand very well the explanation of jvlad... Guileherme, you are missing the point. We'd all like to see PHP 5.3.0 out there. It has a lot to offer, but namespace support is very obviously problematic. That's it, that's all. - Steph -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9166-6902 MSN: [EMAIL PROTECTED] URL: http://blog.bisna.com Rio de Janeiro - RJ/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] true namespaces, yet another point of view
Steph Fox wrote: Lets just let it die. It is un-needed, un-wanted by many, and the end result seems to be less that optimal, or even a true implementation of namespaces. Oddly enough, I agree with Kevin with my heart and soul. But then I hear the howls of outrage from the Other Side, who campaigned without ruth to get namespaces into PHP in the first place. Would someone with authority (Andi? Derick?) like to give an overview of the pros, cons and issues at this point? It's quite difficult to follow all these tiny, endless myco-esque threads, and I share Greg's allergy to wikis for the simple reason that the model is similar. Each item sparks another. - Steph Sorry to clutter the list with yet another post but I am starting to second this feeling. As someone who has already started developing with the 5.3 branch and using namespaces, all this discussion is turning me away. There are so many issues still at this point, how can they possibly be resolved in reasonable amount of time for a 5.3 release? (sigh) I'd rather remove what namespacing I've started already and wait for a solid state, then have to change code later and have to deal with multiple possibilities. I have my opinions how I would use namespaces but have not really voiced them just because there has been way to much discussion. There should be a better way to voice opinions than this madness. IMO :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
