# namespace issues - Thread: https://externals.io/message/40609 - Original archive: https://news-web.php.net/php.internals/40609 - Started by Stanislav Malyshev on 2008-09-22T19:45:51+00:00 - Messages: 30 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/40609.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #40609 — Stanislav Malyshev — 2008-09-22T19:45:51+00:00 URL: https://externals.io/message/40609#40609 Hi! On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about what we'd like to do with namespaces, and we arrived at the following conclusions, which we propose to implement in 5.3: 1. Allow braces for namespaces. So, the syntax for namespaces will be: a) namespace foo; should be first (non-comment) statement in the file, namespace extends to the end of the file or next namespace declaration. b) namespace foo {} can appear anywhere on the top scope (can not be nested). Mixing both syntaxes in one file is not possible. The semantics of both syntaxes will be identical. 2. Simplify resolution order for classes in the namespace: unqualified names are resolved this way: a) check "use" list if the name was defined at "use", follow that resolution b) if not, the name resolves to namespace::name Consequence of this will be that for using internal class inside namespace one would need to refer to it either as ::Foo or do use ::Foo prior to its usage. 3. Functions will not be allowed inside namespaces. We arrived to conclusion that they are much more trouble than they're worth, and summarily we would be better off without them. Most of the functionality could be easily achieved using static class methods, and the rest may be emulated with variable function names, etc. Comments? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #40610 — Jochem Maas — 2008-09-22T21:31:25+00:00 URL: https://externals.io/message/40609#40610 · In reply to: #40609 Stanislav Malyshev schreef: > Hi! > > On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about > what we'd like to do with namespaces, and we arrived at the following > conclusions, which we propose to implement in 5.3: > > 1. Allow braces for namespaces. So, the syntax for namespaces will be: > a) namespace foo; > should be first (non-comment) statement in the file, namespace extends > to the end of the file or next namespace declaration. > b) namespace foo {} > can appear anywhere on the top scope (can not be nested). > Mixing both syntaxes in one file is not possible. The semantics of both > syntaxes will be identical. super. mixing of syntax is a parse error, right? fancy taking a sportsmans bet as to which will be used more in the wild? my 'money' is on syntax B. ;-) > > 2. Simplify resolution order for classes in the namespace: unqualified > names are resolved this way: > a) check "use" list if the name was defined at "use", follow that > resolution > b) if not, the name resolves to namespace::name > Consequence of this will be that for using internal class inside > namespace one would need to refer to it either as ::Foo or do use ::Foo > prior to its usage. again super ... by the sounds of it (I have a sneaking suspicion that some edge-case resolution pains may still crop up but that's what edge-case are all about ... if you could spot them all they'd call you :-)) > 3. Functions will not be allowed inside namespaces. We arrived to > conclusion that they are much more trouble than they're worth, and > summarily we would be better off without them. Most of the functionality > could be easily achieved using static class methods, and the rest may be > emulated with variable function names, etc. given that the general distaste for Greg 'namespace member' proposal this seems like the only other suitable option to resolve current ambiguity issues. using abstract classes to 'namespace' functions has been a quite wide spread practice for a while now anyway. it is likely that function() proponents will balk at the idea of not being able to namespace them but that's less painful to explain than having to deal with the current situation, imho. which leaves the question of namespaced constants ... they suffer the same problems as functions and can also be achieved via classes, I request that you therefore remove them as well as functions. rgds, Jochem PS - pity Greg's patch was so disliked, I rather liked it myself and would have allowed constants and functions inside namespaces ... guess that's life :-) > Comments? --- ## #40613 — Larry Garfield — 2008-09-23T03:39:07+00:00 URL: https://externals.io/message/40609#40613 · In reply to: #40609 On Monday 22 September 2008 2:45:51 pm Stanislav Malyshev wrote: > Hi! > > On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about > what we'd like to do with namespaces, and we arrived at the following > conclusions, which we propose to implement in 5.3: > > 1. Allow braces for namespaces. So, the syntax for namespaces will be: > a) namespace foo; > should be first (non-comment) statement in the file, namespace extends > to the end of the file or next namespace declaration. > b) namespace foo {} > can appear anywhere on the top scope (can not be nested). > Mixing both syntaxes in one file is not possible. The semantics of both > syntaxes will be identical. To clarify, with syntax B you can do multiple namespaces in one file? I have no objection then. > 2. Simplify resolution order for classes in the namespace: unqualified > names are resolved this way: > a) check "use" list if the name was defined at "use", follow that > resolution b) if not, the name resolves to namespace::name > Consequence of this will be that for using internal class inside > namespace one would need to refer to it either as ::Foo or do use ::Foo > prior to its usage. I am OK with this. > 3. Functions will not be allowed inside namespaces. We arrived to > conclusion that they are much more trouble than they're worth, and > summarily we would be better off without them. Most of the functionality > could be easily achieved using static class methods, and the rest may be > emulated with variable function names, etc. > > Comments? "Most of the functionality could be easily achieved using static class methods". As someone who uses both functions and classes with equal comfort, I have to say "GAH, NO NO NO!" to that statement. Classes as pseudo-namespaces are fundamentally wrong. Conceptually they're entirely different things. I have to shut people down every time they try to suggest that in Drupal. It's not just a conceptual issue, either. For a very practical example, consider that a namespaces can be split across any number of files. A class must be all in one file. That means if you want to group functions together, they MUST all be in one single monolithic file. That makes them, sorry, useless for anything even remotely interesting. No, namespaces for functions can most certainly *not* be emulated with either variable functions or static methods. Dropping namespace support for functions makes namespaces mostly useless for anyone who is not 100% OOP. There's no reason to make functions second-class citizens (no pun intended). -- Larry Garfield larry@garfieldtech.com --- ## #40618 — Lester Caine — 2008-09-23T05:13:07+00:00 URL: https://externals.io/message/40609#40618 · In reply to: #40609 Stanislav Malyshev wrote: > Hi! > > On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about > what we'd like to do with namespaces, and we arrived at the following > conclusions, which we propose to implement in 5.3: ..... > 3. Functions will not be allowed inside namespaces. We arrived to > conclusion that they are much more trouble than they're worth, and > summarily we would be better off without them. Most of the functionality > could be easily achieved using static class methods, and the rest may be > emulated with variable function names, etc. > > Comments? *IF* Functions can not be wrapped in a namespace then what *IS* the object of namespace? I understood that namespace was to be a wrapper so that things with the same internal name could be isolated? If one of the main elements of a library can't then be included in the library namespace is there ANY point in adding namespaces at all? -- 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 --- ## #40619 — Dmitry Stogov — 2008-09-23T07:47:30+00:00 URL: https://externals.io/message/40609#40619 · In reply to: #40609 Stanislav Malyshev wrote: > Hi! > > On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about > what we'd like to do with namespaces, and we arrived at the following > conclusions, which we propose to implement in 5.3: > > 1. Allow braces for namespaces. So, the syntax for namespaces will be: > a) namespace foo; > should be first (non-comment) statement in the file, namespace extends > to the end of the file or next namespace declaration. > b) namespace foo {} > can appear anywhere on the top scope (can not be nested). > Mixing both syntaxes in one file is not possible. The semantics of both > syntaxes will be identical. > > 2. Simplify resolution order for classes in the namespace: unqualified > names are resolved this way: > a) check "use" list if the name was defined at "use", follow that > resolution > b) if not, the name resolves to namespace::name > Consequence of this will be that for using internal class inside > namespace one would need to refer to it either as ::Foo or do use ::Foo > prior to its usage. > > 3. Functions will not be allowed inside namespaces. We arrived to > conclusion that they are much more trouble than they're worth, and > summarily we would be better off without them. Most of the functionality > could be easily achieved using static class methods, and the rest may be > emulated with variable function names, etc. > > Comments? Great, lets castrate the language to make it consistent. :( 1. I am fine with (1), except for unspecified scope of "use" statement inside namespace with bracket. I assume it should affect only current declaration and not the following namespace declarations (even with the same name). 2. This is acceptable only if we accept (3) otherwise we will need to write ::strlen() and so on. 3. In case we remove functions we also need to remove constants as they have exactly the same ambiguity problems. It's unclear for me what the following code will define after all (global function or just emit a parse error?) Thanks. Dmitry. --- ## #40620 — Derick Rethans — 2008-09-23T08:07:58+00:00 URL: https://externals.io/message/40609#40620 · In reply to: #40609 > On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk > about what we'd like to do with namespaces, and we arrived at the > following conclusions, which we propose to implement in 5.3: > > 1. Allow braces for namespaces. > 2. Simplify resolution order for classes in the namespace: unqualified > names are resolved this way: > a) check "use" list if the name was defined at "use", follow that > resolution > b) if not, the name resolves to namespace::name > 3. Functions will not be allowed inside namespaces. > Comments? +1 regards, Derick -- HEAD before 5_3!: http://tinyurl.com/6d2esb http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org --- ## #40622 — Lars Strojny — 2008-09-23T08:13:15+00:00 URL: https://externals.io/message/40609#40622 · In reply to: #40609 Hi Stas, Am Montag, den 22.09.2008, 12:45 -0700 schrieb Stanislav Malyshev: [...] > On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about > what we'd like to do with namespaces, and we arrived at the following > conclusions, which we propose to implement in 5.3: Thanks for the effort. > 1. Allow braces for namespaces. So, the syntax for namespaces will be: > a) namespace foo; > should be first (non-comment) statement in the file, namespace extends > to the end of the file or next namespace declaration. > b) namespace foo {} > can appear anywhere on the top scope (can not be nested). > Mixing both syntaxes in one file is not possible. The semantics of both > syntaxes will be identical. > > 2. Simplify resolution order for classes in the namespace: unqualified > names are resolved this way: > a) check "use" list if the name was defined at "use", follow that resolution > b) if not, the name resolves to namespace::name > Consequence of this will be that for using internal class inside > namespace one would need to refer to it either as ::Foo or do use ::Foo > prior to its usage. > > 3. Functions will not be allowed inside namespaces. We arrived to > conclusion that they are much more trouble than they're worth, and > summarily we would be better off without them. Most of the functionality > could be easily achieved using static class methods, and the rest may be > emulated with variable function names, etc. +1 cu, Lars -- Jabber: lars@strojny.net Weblog: http://usrportage.de --- ## #40625 — Karsten Dambekalns — 2008-09-23T08:38:25+00:00 URL: https://externals.io/message/40609#40625 · In reply to: #40609 Hi. For what it's worth, my point of view: Stanislav Malyshev wrote: > 1. Allow braces for namespaces. So, the syntax for namespaces will be: > a) namespace foo; > should be first (non-comment) statement in the file, namespace extends > to the end of the file or next namespace declaration. > b) namespace foo {} > can appear anywhere on the top scope (can not be nested). Full support for the braces, but please *do*not* allow both ways. Why? Perl's "more than one way to do it"? If there's one way, it's clear what to use. I see absolutely no point in this. Really. Please don't. > 2. Simplify resolution order for classes in the namespace: unqualified > names are resolved this way: > a) check "use" list if the name was defined at "use", follow that > resolution > b) if not, the name resolves to namespace::name > Consequence of this will be that for using internal class inside > namespace one would need to refer to it either as ::Foo or do use ::Foo > prior to its usage. Fine with me. I'd use ::Foo for internal classes anyway to avoid speed and ambiguity issues. > 3. Functions will not be allowed inside namespaces. We arrived to > conclusion that they are much more trouble than they're worth, and > summarily we would be better off without them. Most of the functionality > could be easily achieved using static class methods, and the rest may be > emulated with variable function names, etc. We roll everything in classes anyway, so fine with me. Regards, Karsten --- ## #40629 — Kalle Sommer Nielsen — 2008-09-23T10:13:00+00:00 URL: https://externals.io/message/40609#40629 · In reply to: #40625 2008/9/23 Karsten Dambekalns : > Hi. > > For what it's worth, my point of view: > > Stanislav Malyshev wrote: > > […] > > Full support for the braces, but please *do*not* allow both ways. Why? > Perl's "more than one way to do it"? If there's one way, it's clear what to > use. I see absolutely no point in this. Really. Please don't. +1, I would however stick with the braces syntax though, why? Because namespaces aren't really anything than something wrapping around a class in my eyes and I don't see why it needs special treatment, if it has to be one per file, then why not classes aswell, this is like PHP is telling how to design my interface, rather than if I want to have a namespace declaring in a file for some reason or if I wanna have all code mixed in one, then I think I should be allowed to do so, and not having to make multiple files, not that its that big an issue but its still a big -1 with a "ns"-only file. (Please exuse if I have missed something, I tried to keep up with the NS threads, but all these new ones has been alittle to much to overcome). > > > […] > > Fine with me. I'd use ::Foo for internal classes anyway to avoid speed and > ambiguity issues. > > > […] > > We roll everything in classes anyway, so fine with me. > > > Regards, > Karsten > > -- > > > > But overall +1 from me aswell -- Kalle Sommer Nielsen --- ## #40649 — Stanislav Malyshev — 2008-09-23T22:54:00+00:00 URL: https://externals.io/message/40609#40649 · In reply to: #40613 Hi! > To clarify, with syntax B you can do multiple namespaces in one file? I have > no objection then. Yes. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #40657 — Andrew Mason — 2008-09-24T06:56:20+00:00 URL: https://externals.io/message/40609#40657 · In reply to: #40609 Sounds fantastic to me. Not a fan of the {} namespaces but each to their own. > Hi! > > On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about > what we'd like to do with namespaces, and we arrived at the following > conclusions, which we propose to implement in 5.3: > > 1. Allow braces for namespaces. So, the syntax for namespaces will be: > a) namespace foo; > should be first (non-comment) statement in the file, namespace extends to > the end of the file or next namespace declaration. > b) namespace foo {} > can appear anywhere on the top scope (can not be nested). > Mixing both syntaxes in one file is not possible. The semantics of both > syntaxes will be identical. > > 2. Simplify resolution order for classes in the namespace: unqualified names > are resolved this way: > a) check "use" list if the name was defined at "use", follow that resolution > b) if not, the name resolves to namespace::name > Consequence of this will be that for using internal class inside namespace > one would need to refer to it either as ::Foo or do use ::Foo prior to its > usage. > > 3. Functions will not be allowed inside namespaces. We arrived to conclusion > that they are much more trouble than they're worth, and summarily we would > be better off without them. Most of the functionality could be easily > achieved using static class methods, and the rest may be emulated with > variable function names, etc. > > Comments? > -- > Stanislav Malyshev, Zend Software Architect > stas@zend.com http://www.zend.com/ > (408)253-8829 MSN: stas@zend.com --- ## #40660 — david.zuelke@bitextender.com — 2008-09-24T11:45:31+00:00 URL: https://externals.io/message/40609#40660 · In reply to: #40609 Am 22.09.2008 um 21:45 schrieb Stanislav Malyshev: > On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk > about what we'd like to do with namespaces, and we arrived at the > following conclusions, which we propose to implement in 5.3: > > 1. Allow braces for namespaces. So, the syntax for namespaces will be: > > 2. Simplify resolution order for classes in the namespace: > unqualified names are resolved this way: > > 3. Functions will not be allowed inside namespaces. > > Comments? +1 - David --- ## #40665 — Stan Vassilev | FM — 2008-09-24T13:46:38+00:00 URL: https://externals.io/message/40609#40665 · In reply to: #40609 Hi, 1. and 2. are great. I'm happy to see this done. But for 3. I think that's throwing the baby with the bathwater. Since now global classes inside namespaces will need the "use ::Foo;" or "::Foo...", I hope you can give a fresh look at my original idea that both functions and classes require the "use ::foo" or "::foo()" when in a namespace, and leave namespaced functions in. Regards, Stan Vassilev --- ## #40670 — Greg Beaver — 2008-09-24T22:59:05+00:00 URL: https://externals.io/message/40609#40670 · In reply to: #40609 Stanislav Malyshev wrote: > Hi! > > On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about > what we'd like to do with namespaces, and we arrived at the following > conclusions, which we propose to implement in 5.3: > > 1. Allow braces for namespaces. So, the syntax for namespaces will be: > a) namespace foo; > should be first (non-comment) statement in the file, namespace extends > to the end of the file or next namespace declaration. > b) namespace foo {} > can appear anywhere on the top scope (can not be nested). > Mixing both syntaxes in one file is not possible. The semantics of both > syntaxes will be identical. > > 2. Simplify resolution order for classes in the namespace: unqualified > names are resolved this way: > a) check "use" list if the name was defined at "use", follow that > resolution > b) if not, the name resolves to namespace::name > Consequence of this will be that for using internal class inside > namespace one would need to refer to it either as ::Foo or do use ::Foo > prior to its usage. > > 3. Functions will not be allowed inside namespaces. We arrived to > conclusion that they are much more trouble than they're worth, and > summarily we would be better off without them. Most of the functionality > could be easily achieved using static class methods, and the rest may be > emulated with variable function names, etc. I'm happy with #1 although I prefer 1 syntax to rule them all, I can live with this #2 #3 if it also includes removing namespace constants For future post-5.3, functions could be added back in. The ambiguity issue could easily be fixed by having a different scoping resolution operator for namespaced classes vs. namespaced functions/consts. For instance: func(); // namespaced function blah::thing:>func echo blah::thing:>constant; // namespaced constant blah::thing:>constant blah::thing:>$var = 1; // namespaced variable blah::thing:>$var (pure fantasy, but illustrates the point) blah::thing::$var = 1; // namespaced class blah::thing, class variable $var ?> Before anyone gets all hyper, my point is *not* to introduce :>, but to explain that it is in fact technically feasible to extend the definition of namespaces later to add support for non-class elements and it would work just fine. It is, however, not going to be possible to do this post-5.3 without the change above. Note that we have a different operator for dereferencing static class members (::) versus object members (->) for the reason that the thing being dereferenced is different. Namespaces are in fact different from classes, so the problem with the current implementation is that the same operator (::) used for both means we cannot allow any ambiguity between namespace contents and class contents. As long as classes cannot contain other classes: then :: can be used for both namespace operator and static class operator if functions/constants are removed from namespaces. Greg --- ## #40672 — Steph Fox — 2008-09-24T23:20:54+00:00 URL: https://externals.io/message/40609#40672 · In reply to: #40670 > Before anyone gets all hyper, my point is *not* to introduce :>, but to > explain that it is in fact technically feasible to extend the definition > of namespaces later to add support for non-class elements and it would > work just fine. > > It is, however, not going to be possible to do this post-5.3 without the > change above. Damn Greg, I love the way your head works :) Thank you for being the only person to date to think "ok so we start low and then expand" and have some clue as to what "expand" might mean, and the restrictions it might put on whatever is done now. The main concern I have with namespace support is that it shouts "leave it 'til 6.0" at me because it's really not there yet, even at conceptual level. I'm not the only one thinking this way. To quote jvlad (the person with no name) in an off-list exchange, "language syntax should be developed after the philosophy, not before, and what people still did not agree of is the philosophy of the namespaces." I seriously think he's right. Maybe we should all just step back at this point and consider the phrase "third time lucky"? - Steph --- ## #40683 — Lukas Kahwe Smith — 2008-09-25T14:08:27+00:00 URL: https://externals.io/message/40609#40683 · In reply to: #40613 > "Most of the functionality could be easily achieved using static class > methods". > > As someone who uses both functions and classes with equal comfort, I > have to > say "GAH, NO NO NO!" to that statement. Classes as pseudo- > namespaces are > fundamentally wrong. Conceptually they're entirely different > things. I have > to shut people down every time they try to suggest that in Drupal. > > It's not just a conceptual issue, either. For a very practical > example, > consider that a namespaces can be split across any number of files. > A class > must be all in one file. That means if you want to group functions > together, > they MUST all be in one single monolithic file. That makes them, > sorry, > useless for anything even remotely interesting. > > No, namespaces for functions can most certainly *not* be emulated > with either > variable functions or static methods. Dropping namespace support for > functions makes namespaces mostly useless for anyone who is not 100% > OOP. > There's no reason to make functions second-class citizens (no pun > intended). sure point taken on the monolithic files, when sticking different functions into classes just for the sake of them then becoming namespaceable. but how would allowing functions in namespaces solve this issue? regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #40684 — Lukas Kahwe Smith — 2008-09-25T14:09:16+00:00 URL: https://externals.io/message/40609#40684 · In reply to: #40619 > Stanislav Malyshev wrote: > > […] > > Great, lets castrate the language to make it consistent. :( > > 1. I am fine with (1), except for unspecified scope of "use" statement > inside namespace with bracket. I assume it should affect only current > declaration and not the following namespace declarations (even with > the > same name). > > 2. This is acceptable only if we accept (3) otherwise we will need to > write ::strlen() and so on. > > 3. In case we remove functions we also need to remove constants as > they > have exactly the same ambiguity problems. It's unclear for me what the > following code will define after all (global function or just emit a > parse error?) > > namespace foo { > function bar() { > } > } > ?> Right, Stas, did you also discuss removal of constants? Seems logical as the really the same arguments apply. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #40689 — Stanislav Malyshev — 2008-09-25T17:58:47+00:00 URL: https://externals.io/message/40609#40689 · In reply to: #40684 Hi! > Right, Stas, did you also discuss removal of constants? Seems logical as > the really the same arguments apply. IMO constants do not produce that much trouble, since they are not as extensively used than methods and functions. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #40697 — Larry Garfield — 2008-09-26T04:36:05+00:00 URL: https://externals.io/message/40609#40697 · In reply to: #40683 On Thursday 25 September 2008 9:08:27 am Lukas Kahwe Smith wrote: > > […] > > sure point taken on the monolithic files, when sticking different > functions into classes just for the sake of them then becoming > namespaceable. but how would allowing functions in namespaces solve > this issue? > > regards, > Lukas Kahwe Smith > mls@pooteeweet.org Functions in namespaces serve the same purpose as classes in namespaces, for whatever that purpose is this week. :-) It allows for shorter function names for related functions (that cannot be part of the same class for practical architectural reasons, as mentioned, or for conceptual reasons) and for clustering of functionality in ways that classes are ill-suited for. Another advantage is for differentiation. One problem we have run into in Drupal is that if we have a function named "foo_bar_baz()", is that the "bar_baz()" function of the "foo" module/namespace or is it the "baz()" function of the "foo_bar" module/namespace? (We are trying to implement some performance enhancement logic that depends on knowing the difference between those two case.) Note that we cannot forbid such modules/namespaces as anyone can write a module named whatever they feel like. In theory we could use a double underscore, foo__bar_baz(), but that's just as silly as class Zend_Controller_Factory_View_Plugin_Thing. Ideally we could do foo::bar_baz(), eliminate the ambiguity, and make it easier for module developers, too. Just define your module as a namespace and then you always have a function bar_baz() inside it. And we can continue to split modules across multiple files (absolutely critical for performance) and allow modules to define functions on behalf of another module (absolutely critical for functionality). See the sample code I posted back on 9/9 in response to your request for implementations. My point in the GP post is that "you can just use static methods" to emulate namespaces for functions is wrong, and cannot be used as an argument that functions do not need or should not get namespaces. -- Larry Garfield larry@garfieldtech.com --- ## #40698 — Arvids Godjuks — 2008-09-26T05:43:44+00:00 URL: https://externals.io/message/40609#40698 · In reply to: #40609 2008/9/22 Stanislav Malyshev > Hi! > > 3. Functions will not be allowed inside namespaces. We arrived to > conclusion that they are much more trouble than they're worth, and summarily > we would be better off without them. Most of the functionality could be > easily achieved using static class methods, and the rest may be emulated > with variable function names, etc. > > Comments? > -- > Stanislav Malyshev, Zend Software Architect > stas@zend.com http://www.zend.com/ > (408)253-8829 MSN: stas@zend.com > > -- > > That means, that if I have a tiny, 70-100 line script and I use a package in a namespace with some global functionality - it should be 100% OOP? Sorry, but that's OOP for the sake of OOP. It's like writing "Hello world!" using patterns (here is an example: http://www.phppatterns.com/docs/design/hello_world_in_patterns) -1 on this. --- ## #40700 — Nathan Rixham — 2008-09-26T09:48:45+00:00 URL: https://externals.io/message/40609#40700 · In reply to: #40698 Arvids Godjuks wrote: > 2008/9/22 Stanislav Malyshev > > > […] > > > That means, that if I have a tiny, 70-100 line script and I use a package in > a namespace with some global functionality - it should be 100% OOP? Sorry, > but that's OOP for the sake of OOP. It's like writing "Hello world!" using > patterns (here is an example: > http://www.phppatterns.com/docs/design/hello_world_in_patterns) > > -1 on this. > my god that's basically a PHP version of the Java "Hello World" 1. Allow braces for namespaces. So, the syntax for namespaces will be: > a) namespace foo; > should be first (non-comment) statement in the file, namespace extends > to the end of the file or next namespace declaration. > b) namespace foo {} > can appear anywhere on the top scope (can not be nested). > Mixing both syntaxes in one file is not possible. The semantics of both > syntaxes will be identical. I'm fine with that, personally I'd like having only the {}-Syntax but as many people want both, well, ... For future times (6.0) we might think about adding nesting support - if we get it working good with the engine, but no show-stopper, we're "delayed" enough... > 2. Simplify resolution order for classes in the namespace: unqualified > names are resolved this way: > a) check "use" list if the name was defined at "use", follow that resolution > b) if not, the name resolves to namespace::name > Consequence of this will be that for using internal class inside > namespace one would need to refer to it either as ::Foo or do use ::Foo > prior to its usage. That will hurt a bit when working with DOM for example, but still +1. > 3. Functions will not be allowed inside namespaces. We arrived to > conclusion that they are much more trouble than they're worth, and > summarily we would be better off without them. Most of the functionality > could be easily achieved using static class methods, and the rest may be > emulated with variable function names, etc. That's fine, I'm not sure about constants, neither one way nor the other, but in general I see some support for dropping them. johannes --- ## #40797 — Daniel Convissor — 2008-09-30T03:25:31+00:00 URL: https://externals.io/message/40609#40797 · In reply to: #40619 > Stanislav Malyshev wrote: > > […] > > 3. In case we remove functions we also need to remove constants as they > have exactly the same ambiguity problems. Classes inside name spaces raise the same issue: The currently proposed operator is a major problem. Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 --- ## #40814 — Vesselin Kenashkov — 2008-10-01T07:34:35+00:00 URL: https://externals.io/message/40609#40814 · In reply to: #40609 I'm -1 for "removing constants and functions from the namespaces". As I wrote already in another thread, is it possible to have a fatal error thrown when the engine detects an ambiguity situation? Are there any logical (i mean from OOP point of view) or internals (performance and so on) problems with this solution? In my opinion is better than dropping funcs & consts. Vesselin Kenashkov > Hi! > > On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about > what we'd like to do with namespaces, and we arrived at the following > conclusions, which we propose to implement in 5.3: > > 1. Allow braces for namespaces. So, the syntax for namespaces will be: > a) namespace foo; > should be first (non-comment) statement in the file, namespace extends to > the end of the file or next namespace declaration. > b) namespace foo {} > can appear anywhere on the top scope (can not be nested). > Mixing both syntaxes in one file is not possible. The semantics of both > syntaxes will be identical. > > 2. Simplify resolution order for classes in the namespace: unqualified > names are resolved this way: > a) check "use" list if the name was defined at "use", follow that > resolution > b) if not, the name resolves to namespace::name > Consequence of this will be that for using internal class inside namespace > one would need to refer to it either as ::Foo or do use ::Foo prior to its > usage. > > 3. Functions will not be allowed inside namespaces. We arrived to > conclusion that they are much more trouble than they're worth, and summarily > we would be better off without them. Most of the functionality could be > easily achieved using static class methods, and the rest may be emulated > with variable function names, etc. > > Comments? > -- > Stanislav Malyshev, Zend Software Architect > stas@zend.com http://www.zend.com/ > (408)253-8829 MSN: stas@zend.com --- ## #40817 — Gregory Beaver — 2008-10-01T12:59:34+00:00 URL: https://externals.io/message/40609#40817 · In reply to: #40814 Vesselin Kenashkov wrote: > I'm -1 for "removing constants and functions from the namespaces". As I > wrote already in another thread, is it possible to have a fatal error thrown > when the engine detects an ambiguity situation? Are there any logical (i > mean from OOP point of view) or internals (performance and so on) problems > with this solution? In my opinion is better than dropping funcs & consts. Hi, There are problems with the internal implementation. For instance, constants do not store the line number on which they were created, and are not actually registered as existing until runtime, so conflict checks would happen at runtime. This would mean your application could work perfectly until a rarely executed branch of code is accessed and boom, fatal error. Greg --- Next page: https://externals.io/message/40609.md?page=2