# alpha3 - Thread: https://externals.io/message/40711 - Original archive: https://news-web.php.net/php.internals/40711 - Started by Lukas Kahwe Smith on 2008-09-26T19:58:40+00:00 - Messages: 26 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/40711.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 --- ## #40711 — Lukas Kahwe Smith — 2008-09-26T19:58:40+00:00 URL: https://externals.io/message/40711#40711 Hi, We are not yet ready to schedule alpha3, but I am hoping we can do it in the first half of October. This is just a heads up to tell everybody that yes there will be an alpha3 and a general timeframe. This is not an invitation to go crazy and start committing features at all. If you have something that you think is very low risk, unquestionably useful, with ready tests and patches, then feel free to approach me and Johannes. Otherwise just help us to get 5.3.0 out the door, so that you can add whatever niceties into 5.3.1 :) regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #40720 — Steph Fox — 2008-09-27T00:25:42+00:00 URL: https://externals.io/message/40711#40720 · In reply to: #40711 Hey Lukas, Johannes, all... > We are not yet ready to schedule alpha3, but I am hoping we can do it in > the first half of October. This is just a heads up to tell everybody that > yes there will be an alpha3 and a general timeframe. > > This is not an invitation to go crazy and start committing features at > all. If you have something that you think is very low risk, > unquestionably useful, with ready tests and patches, then feel free to > approach me and Johannes. Otherwise just help us to get 5.3.0 out the > door, so that you can add whatever niceties into 5.3.1 :) Does that mean we can drop namespace support until 6.0? Please? Rationale: 1) It's uber-contentious, and all the good stuff's only just starting to turn up that would allow sane design decisions 2) If it's released as-is, there would be no going back due to BC concerns Simple as. I'm just worried about it all, and 5.3 should've been out months ago because it's otherwise brilliant. - Steph --- ## #40721 — Stanislav Malyshev — 2008-09-27T00:28:45+00:00 URL: https://externals.io/message/40711#40721 · In reply to: #40720 Hi! > Does that mean we can drop namespace support until 6.0? > > Please? > Rationale: > > 1) It's uber-contentious, and all the good stuff's only just starting to > turn up that would allow sane design decisions I don't know what "uber-contentios" means, but no solution is going to satisfy 100% of people. The solution we have now is good for many uses, even if not for 100% of them, and delaying this much needed feature because of couple of vocal people of the list is just insane. > 2) If it's released as-is, there would be no going back due to BC concerns Going back to what? To endless discussions about separator characters? No, we are not, and good riddance. Imperfect solution is much better than perpetual absence of any solution. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #40723 — Steph Fox — 2008-09-27T00:38:36+00:00 URL: https://externals.io/message/40711#40723 · In reply to: #40721 Oh Stas, we have to fall out now! > Imperfect solution is much better than perpetual absence of any solution. See, I'm not sure I agree with that. I think 'imperfect but basic solution that can be expanded on' would be a better approach than trying to do it all in one hit. And I still think putting it off to PHP 6 would be a smart move. It's the major thing that's holding up 5.3. - Steph --- ## #40724 — Stanislav Malyshev — 2008-09-27T01:26:17+00:00 URL: https://externals.io/message/40711#40724 · In reply to: #40723 Hi! > And I still think putting it off to PHP 6 would be a smart move. It's > the major thing that's holding up 5.3. Nothing is "holding" anything. Lukas has release schedule, and namespace implementation will fit it. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #40725 — Greg Beaver — 2008-09-27T04:10:50+00:00 URL: https://externals.io/message/40711#40725 · In reply to: #40723 Steph Fox wrote: > Oh Stas, we have to fall out now! > > > […] > > See, I'm not sure I agree with that. > > I think 'imperfect but basic solution that can be expanded on' would be > a better approach than trying to do it all in one hit. > > And I still think putting it off to PHP 6 would be a smart move. It's > the major thing that's holding up 5.3. Hi, I have to respectfully disagree with both of you: Stas: choosing an imperfect solution when a better one already exists is just plain stupid, and isn't what you want *or* what you suggested - the solution you, Liz, Marcus and Andi proposed is not imperfect, it is consistent, robust and far better than the existing CVS implementation of namespaces. Don't sell yourself so short! :) Steph: the limited solution proposed by Stas and company (removing functions [and I would add constants]/fixing name resolution) *is* a basic solution that can be expanded on. I outlined the steps in my reply. It's the best solution to the problem, not an imperfect one. A namespace solution that works brilliantly for classes will satisfy at least 2/3 of the users who want it. Adding support for functions, constants and even variables is actually quite do-able with the solution I suggested (different separator between namespace name and function/constant/variable name) and can be added easily. file 1: file 2: myfunc; // separator :> could be anything echo foo::bar:>$myvar; echo foo::bar:>myconst; // all of the below would also be possible, although we may choose not to implement things like use of a variable use foo::bar::myclass, foo::bar:>$myvar, foo::bar:>myfunc(), foo::bar:>myconst, foo::bar; ?> So the question of whether we are making a mistake with Stas's suggestion relayed from ZendCon is debunked by 2 facts: 1) the implementation is a reduced set based on the existing namespace implementation which has been beaten up and tested thoroughly, and because it is simpler, will be even easier to verify its veracity. 2) it can be easily extended to add support later for other components like functions, while preserving 100% BC with the current::implementation. There is also jvlad's suggestion to consider, but in my opinion, this trades one conflict for another, as this code would be a fatal error: Unless we also used my suggestion of having a namespace member separator different from scope resolution operator. In addition, Rasmus has pointed out many times in the past that allowing changing the namespace of external code depending on code load order would simply break opcode caching for PHP. Greg --- ## #40728 — Alexey Zakhlestin — 2008-09-27T07:45:35+00:00 URL: https://externals.io/message/40711#40728 · In reply to: #40725 > I have to respectfully disagree with both of you: > > Stas: choosing an imperfect solution when a better one already exists is > just plain stupid, and isn't what you want *or* what you suggested - the > solution you, Liz, Marcus and Andi proposed is not imperfect, it is > consistent, robust and far better than the existing CVS implementation > of namespaces. Don't sell yourself so short! :) > > Steph: the limited solution proposed by Stas and company (removing > functions [and I would add constants]/fixing name resolution) *is* a > basic solution that can be expanded on. I outlined the steps in my > reply. It's the best solution to the problem, not an imperfect one. A > namespace solution that works brilliantly for classes will satisfy at > least 2/3 of the users who want it. I guess, I am in these 2/3's. Limited solution (with a promise to extend it later) would work for me, perfectly. -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ --- ## #40729 — Ilia Cheishvili — 2008-09-27T08:09:34+00:00 URL: https://externals.io/message/40711#40729 · In reply to: #40728 I would definitely have to agree. I would much prefer to have a minimal solution implemented and then to iterate over it in the future than to try to figure out the perfect implementation the first time. Just from watching where the thread about namespaces has gone, I would definitely have to say that we have set the expectation for ourselves that the first implementation will be the only one and therefore has to be perfect. And that's hard to live up to :) Ilia On Sat, Sep 27, 2008 at 1:45 AM, Alexey Zakhlestin wrote: > On Sat, Sep 27, 2008 at 8:10 AM, Greg Beaver > wrote: > > […] > > I guess, I am in these 2/3's. Limited solution (with a promise to > extend it later) would work for me, perfectly. > > -- > Alexey Zakhlestin > http://blog.milkfarmsoft.com/ --- ## #40733 — Steph Fox — 2008-09-27T09:11:24+00:00 URL: https://externals.io/message/40711#40733 · In reply to: #40725 Hi Greg, > Steph: the limited solution proposed by Stas and company (removing > functions [and I would add constants]/fixing name resolution) *is* a > basic solution that can be expanded on. I outlined the steps in my > reply. It's the best solution to the problem, not an imperfect one. A > namespace solution that works brilliantly for classes will satisfy at > least 2/3 of the users who want it. Great! So why isn't it already in CVS? > Adding support for functions, constants and even variables is actually > quite do-able with the solution I suggested (different separator between > namespace name and function/constant/variable name) and can be added > easily. Ah.... that's why it isn't already in. I agree with you that this would be a workable solution for 99% of the problems uncovered so far, but... man, it's fugly! - Steph --- ## #40737 — jvlad — 2008-09-27T13:59:36+00:00 URL: https://externals.io/message/40711#40737 · In reply to: #40725 > Adding support for functions, constants and even variables is actually > quite do-able with the solution I suggested (different separator between > namespace name and function/constant/variable name) and can be added > easily. > Adding support for functions, constants and even variables is actually > quite do-able with the solution I suggested (different separator between > namespace name and function/constant/variable name) and can be added > easily. Greg, Does it mean that the namespace separator will not be (or likely not to be) the same when you need access to namespaced classes vs namespaced functions? What's about consistency of the design? If you can't resolve the ambiguity or any other problems around namespaces without changing the separator, why not to change it for classes too? -JV --- ## #40738 — Gregory Beaver — 2008-09-27T20:15:17+00:00 URL: https://externals.io/message/40711#40738 · In reply to: #40737 jvlad wrote: > > […] > > > […] > > > Greg, > > Does it mean that the namespace separator will not be (or likely not to be) > the same when you need access to namespaced classes vs namespaced functions? > What's about consistency of the design? If you can't resolve the ambiguity > or any other problems around namespaces without changing the separator, why > not to change it for classes too? Hi, The patch I posted here: http://pear.php.net/~greg/ns.element.patch.txt does exactly what you are talking about. For some reason, some people find this too difficult to digest. I've already expressed my opinion on the matter (after all, I did spend almost a week developing the patch). Greg --- ## #40741 — Steph Fox — 2008-09-28T14:29:04+00:00 URL: https://externals.io/message/40711#40741 · In reply to: #40738 Hi Greg, > The patch I posted here: > > http://pear.php.net/~greg/ns.element.patch.txt > > does exactly what you are talking about. For some reason, some people > find this too difficult to digest. I've already expressed my opinion on > the matter (after all, I did spend almost a week developing the patch). OK, I'll bite. First off, I find '->' just as much as potential source of confusion as '::', and for the exact same reason: it's already used to express a relationship in PHP. All this says to me is we still don't have the right ns separator. It's clear that PHP 5.3 shouldn't go out with '::' as the ns separator even if only classes are supported, despite the fact that the current implementation appears solid in every other respect at that level. It can't go out that way because we already know there will be huge user pressure to extend namespace support beyond classes. This wasn't part of the original remit, but we now know we need to allow for it before ns support is part of an official release. It's equally clear (to me at least) that having two ways to express a namespaced element depending on context would be a Bad Thing [TM]. The only reason that's even come up for consideration is the ambiguity caused by the ns separator we already have. Basically, I think you're trying to find solutions to the wrong problem, since at present ns support doesn't exist in any official PHP release. Your approach assumes a BC consideration that (thankfully) doesn't exist yet. I don't want to see that whole ns separator debate all over again any more than you do, but I really don't see a good way to avoid it... sorry. And if that means introducing a new symbol... it can't really be staved off until 6.0, unless we don't care about 6.0 code not running under 5.3. The other option of course would be to say "ns support will **never** be extended beyond classes", and actually mean it. - Steph --- ## #40742 — david.zuelke@bitextender.com — 2008-09-28T15:31:08+00:00 URL: https://externals.io/message/40711#40742 · In reply to: #40741 +1, or: "Do, or do not. There is no 'try.'" - David > Hi Greg, > > > […] > > OK, I'll bite. > > First off, I find '->' just as much as potential source of confusion > as '::', and for the exact same reason: it's already used to express > a relationship in PHP. All this says to me is we still don't have > the right ns separator. > > It's clear that PHP 5.3 shouldn't go out with '::' as the ns > separator even if only classes are supported, despite the fact that > the current implementation appears solid in every other respect at > that level. It can't go out that way because we already know there > will be huge user pressure to extend namespace support beyond > classes. This wasn't part of the original remit, but we now know we > need to allow for it before ns support is part of an official release. > > It's equally clear (to me at least) that having two ways to express > a namespaced element depending on context would be a Bad Thing [TM]. > The only reason that's even come up for consideration is the > ambiguity caused by the ns separator we already have. > > Basically, I think you're trying to find solutions to the wrong > problem, since at present ns support doesn't exist in any official > PHP release. Your approach assumes a BC consideration that > (thankfully) doesn't exist yet. > > I don't want to see that whole ns separator debate all over again > any more than you do, but I really don't see a good way to avoid > it... sorry. > > And if that means introducing a new symbol... it can't really be > staved off until 6.0, unless we don't care about 6.0 code not > running under 5.3. > > The other option of course would be to say "ns support will > **never** be extended beyond classes", and actually mean it. > > - Steph --- ## #40744 — Ryan Panning — 2008-09-28T22:21:29+00:00 URL: https://externals.io/message/40711#40744 · In reply to: #40741 Steph Fox wrote: > I don't want to see that whole ns separator debate all over again any > more than you do, but I really don't see a good way to avoid it... sorry. +1, I second this completely From someone who *was* using namespaces developing against the 5.3 branch, this is going to happen sooner or later. I found that :: just causes to many questions when used in namespaces. Using :: or -> just for the sake of reusing existing tokens is just wrong. I'm in favor of # if it can be worked out. --- ## #40776 — Jordi Boggiano — 2008-09-29T14:43:06+00:00 URL: https://externals.io/message/40711#40776 · In reply to: #40744 > +1, I second this completely > > From someone who *was* using namespaces developing against the 5.3 branch, > this is going to happen sooner or later. I found that :: just causes to many > questions when used in namespaces. Using :: or -> just for the sake of > reusing existing tokens is just wrong. I'm in favor of # if it can be worked > out. +1 as well, but I must say # is not right, it is a very black/filled character, as in it doesn't visually#separate#words#that#well. Using the dot would be really nice, but I guess it would break with something like this : "concat".foo.bar()."baz" so it's not an option. Using a single colon might work out ? foo:bar:class::staticFunc() sounds good to me, but maybe I missed something. I also had the idea of using the underscore, even though I guess we can't go through with this as people _might_ have used double underscores in their class names, I guess it would work out quite well with single underscores, for example : class Foo_Bar { public static function callMe() } Foo_Bar::callMe(); ..would be read as class Bar in namespace Foo, but it would be transparent to everyone since if you use something with a fully qualified name you don't need to "use" them, right ? Anyway it's just a couple ideas, but please stop holding on to that double colon. -- Jordi --- ## #40778 — Lukas Kahwe Smith — 2008-09-29T15:01:36+00:00 URL: https://externals.io/message/40711#40778 · In reply to: #40776 Hi, Ok before we all go crazy with the NS separator debate, some reading (which also links to a few interesting posts/sites): http://marc.info/?l=php-internals&m=113313170231815&w=2 http://marc.info/?l=php-internals&m=113345477123705&w=2 http://marc.info/?l=php-internals&m=117742643931293&w=2 I have also emailed Jessie to see if we can somehow resurrect the content on http://www.phpnamespaces.org/ I invite anyone that seriously wants to have that debate again to scavenge through all of that, write a page on the wiki first. regards, Lukas --- ## #40781 — Arvids Godjuks — 2008-09-29T16:05:48+00:00 URL: https://externals.io/message/40711#40781 · In reply to: #40776 2008/9/29 Jordi Boggiano > > > […] > branch, > > […] > many > > […] > worked > > […] > > +1 as well, but I must say # is not right, it is a very black/filled > character, as in it doesn't visually#separate#words#that#well. Using > the dot would be really nice, but I guess it would break with > something like this : "concat".foo.bar()."baz" so it's not an option. > > Using a single colon might work out ? foo:bar:class::staticFunc() > sounds good to me, but maybe I missed something. > > I also had the idea of using the underscore, even though I guess we > can't go through with this as people _might_ have used double > underscores in their class names, I guess it would work out quite well > with single underscores, for example : > > class Foo_Bar { > public static function callMe() > } > Foo_Bar::callMe(); > > ..would be read as class Bar in namespace Foo, but it would be > transparent to everyone since if you use something with a fully > qualified name you don't need to "use" them, right ? > > Anyway it's just a couple ideas, but please stop holding on to that > double colon. > > -- > Jordi > > -- > > > > I agree with you totally that :: makes too much trouble - people are trying to fix all issues for a few month's now and every time it results in "we cut $something then it works!" and of course developers as myself start to shout that we don't need namespaces half implemented, because they are useless when. I took part in discussion in two threads by this time: here: solving the namespace conflict issues between function/static method class constant/ns constant AND here: true namespaces, yet another point of view Firstly I also proposed . as a separator, but it has issues with constants: That now results in "hello world!". So if CONST is a namespace and we have constant named the same - a problem occures. Well, that can be worked around - we can check for name collision and give an error, but I think people will shout at that as bad, wy we can't have namespace and constant named equaly? Well, I would live with that perfectly, but something tells me developers will be against this. Other problem is resolution. MYNAMESPACE.Test::print() - what is it? A constant named MYNAMESPACE or a namespace itself? As I understand, during compile time that isn't a problem to resolve whether it is constant or namespace? Ok, we done that. Then we hit SOMETHING witch isn't a constant, not namespace. Ups, what error should we give? Undefined constant or missing namespace? Well, as i think of this - only good solution is Fatal error, but then any forgottent to be set constant will result in fatal error. To me that is good - I woun't forget to define any constants! But as I predict - most will shout that it's too harsh, and they will be right at some point (I myself started with a Pascal, so to me an undefined variable === compile error (Fatal error in PHP terms), so it's natural to me to have a Fatal at this point). So -1 on "." So . is more suitable than ::, but also has it's problems - easier o resolve, but problems. In thouse threads people presented next options for namespace separators: 1). ".." as separator. Well, two symbols, has no side effects, but looks quite strage: namespace A..B::staticMethod(). I don't think it's a good one, so -1. 2). Someone proposed \ as separator. A\B::staticMethod() - Looks crazy, isn't it? And we all know, that \ mostly has special meaning in programming languages as escape character. -1. 3). "#" & Co. A#B::staticMethod() - no side effects, bot looks dirty. -1 from me. 4). ::: or ::::. If ::: makes sence, than that man, who proposed :::: should be joking. ::: - no side effects, just little more to type. A candidate. Neither -1, nor +1. So as prevoius speaker suggested, and I personaly got to conclusion in other thread that ":" is ideal. Short, isn't taken. test(); :phpversion(); ?> Looks great, clearly seen and distinguished from :: . So maybe it is time to stop arguing and maybe use :? Because it finaly comes out as good choise in many threads. Please, think about us - developers! We don't want complicated resoution rules. We don't want half functional namespaces with only classes or without constants, ect. And : is something is natural, because we allready have :: separator for static methods. Easy to understand, handy to use, everybody is happy. Don't you want that? +1 for : from me. P.S. There always will be people, who will be against any suggestions. Because that's phycology. They wana be in center of the attension. Just make a vote thread about : and I think you will get a YES for that. --- ## #40783 — Vesselin Kenashkov — 2008-09-29T16:30:00+00:00 URL: https://externals.io/message/40711#40783 · In reply to: #40781 I thought that : was rejected because of the terniary operator? I'm not going to search now for the discussion but for sure there were serious objections against : , otherwise it would be natural to use it. How you propose to handle the ambiguities like: Parenthesis are a solution, but I have no knoledge of the internal parsing hence I dont know is it possible. AFAIK the actual problem with the current implementation with :: is that is ambigous like: My proposal is (if possible/reasonable/performance wise of course) to have a fatal error thrown when during the parse time the engine discovers duplicates like the one described above. What is the point to name in the same way a class and a static method and a namespace and a function in the same way? In my (very humble) opinion this is the best solution, because we keep the :: operator that we are familiar with, the ambiguity is resolved (just not allowing it) and (I guess) the php 5.3 will not be delayed much. Is there any other logical problem with the namespaces besides this ambiguity? Have I missed something else? In fact I'm using a lot the namespaces in their current implementation and I'm very happy with it. I Never had problems with the ambiguity, because I never even needed to use duplicated names for the different objects (classes, constants, static methods, functions). Vesselin Kenashkov On Mon, Sep 29, 2008 at 7:05 PM, Arvids Godjuks wrote: > 2008/9/29 Jordi Boggiano > > > […] > wrote: > > […] > I agree with you totally that :: makes too much trouble - people are trying > to fix all issues for a few month's now and every time it results in "we > cut > $something then it works!" and of course developers as myself start to > shout > that we don't need namespaces half implemented, because they are useless > when. > > I took part in discussion in two threads by this time: > here: solving the namespace conflict issues between function/static method > class constant/ns constant > AND > here: true namespaces, yet another point of view > > Firstly I also proposed . as a separator, but it has issues with constants: > define('CONST', 'hello '); > > class Test { > static function print() { > return 'world!'; > } > } > > echo CONST.Test::print(); > ?> > > That now results in "hello world!". So if CONST is a namespace and we have > constant named the same - a problem occures. Well, that can be worked > around > - we can check for name collision and give an error, but I think people > will > shout at that as bad, wy we can't have namespace and constant named equaly? > Well, I would live with that perfectly, but something tells me developers > will be against this. > Other problem is resolution. > > MYNAMESPACE.Test::print() - what is it? A constant named MYNAMESPACE or a > namespace itself? > As I understand, during compile time that isn't a problem to resolve > whether > it is constant or namespace? Ok, we done that. Then we hit SOMETHING witch > isn't a constant, not namespace. Ups, what error should we give? Undefined > constant or missing namespace? Well, as i think of this - only good > solution > is Fatal error, but then any forgottent to be set constant will result in > fatal error. To me that is good - I woun't forget to define any constants! > But as I predict - most will shout that it's too harsh, and they will be > right at some point (I myself started with a Pascal, so to me an undefined > variable === compile error (Fatal error in PHP terms), so it's natural to > me > to have a Fatal at this point). > So -1 on "." > > So . is more suitable than ::, but also has it's problems - easier o > resolve, but problems. > In thouse threads people presented next options for namespace separators: > 1). ".." as separator. Well, two symbols, has no side effects, but looks > quite strage: namespace A..B::staticMethod(). I don't think it's a good > one, > so -1. > 2). Someone proposed \ as separator. A\B::staticMethod() - Looks crazy, > isn't it? And we all know, that \ mostly has special meaning in programming > languages as escape character. -1. > 3). "#" & Co. A#B::staticMethod() - no side effects, bot looks dirty. -1 > from me. > 4). ::: or ::::. If ::: makes sence, than that man, who proposed :::: > should > be joking. ::: - no side effects, just little more to type. A candidate. > Neither -1, nor +1. > > So as prevoius speaker suggested, and I personaly got to conclusion in > other > thread that ":" is ideal. Short, isn't taken. > D:F:G:B:H use A; > A:B::staticMethod(); > A:B->test(); > :phpversion(); > ?> > > Looks great, clearly seen and distinguished from :: . > So maybe it is time to stop arguing and maybe use :? Because it finaly > comes > out as good choise in many threads. > Please, think about us - developers! We don't want complicated resoution > rules. We don't want half functional namespaces with only classes or > without > constants, ect. And : is something is natural, because we allready have :: > separator for static methods. Easy to understand, handy to use, everybody > is > happy. Don't you want that? > > +1 for : from me. > > P.S. There always will be people, who will be against any suggestions. > Because that's phycology. They wana be in center of the attension. Just > make > a vote thread about : and I think you will get a YES for that. --- ## #40784 — Steph Fox — 2008-09-29T16:34:00+00:00 URL: https://externals.io/message/40711#40784 · In reply to: #40781 > +1 for : from me. Ternary. Operator. Trouble. Otherwise it'd get my vote too. - Steph --- ## #40786 — Stefan Walk — 2008-09-29T16:35:45+00:00 URL: https://externals.io/message/40711#40786 · In reply to: #40781 On Monday 29 September 2008 18:05:48 Arvids Godjuks wrote: > So as prevoius speaker suggested, and I personaly got to conclusion in > other thread that ":" is ideal. Short, isn't taken. $a = $b?A:B:C:D; --- ## #40788 — Janusz Lewandowski — 2008-09-29T17:24:54+00:00 URL: https://externals.io/message/40711#40788 · In reply to: #40786 Monday 29 September 2008 18:35:45 Stefan Walk napisał(a): > On Monday 29 September 2008 18:05:48 Arvids Godjuks wrote: > > […] > > $a = $b?A:B:C:D; Will _you_ write such code? No. Will anybody from this list write such code? No. Will any good PHP developer write such code? No. So why do you think that's a problem? It would be a problem only for people writing such code, and I think that such people will be able to do something stupid with every syntax. PS. Somebody might also write $a = $b ? $c ? true : false ? true : false : true; Does it mean, that ternary is bad? Of course not. PS2. *I* *personally* like :: much more than : and I think, that conflicting namespaced functions and class functions should just result in an error, as has Vesselin Kenashkov suggested. --- ## #40789 — Jordi Boggiano — 2008-09-29T17:29:30+00:00 URL: https://externals.io/message/40711#40789 · In reply to: #40786 > > > […] > > $a = $b?A:B:C:D; It's only a problem when you use fully qualified names inside a ternary operation, and can easily be fixed with parenthesis in this particular case, so it still looks much better than the current situation to me, and I'm pretty sure everyone would agree on using ":" as a separator if it weren't from that small glitch. The use of parenthesis is not that big a deal if it's restricted to ternary operator uses, there are some places already where you're forced to use them for disambiguation. We could also keep ::foo() as the way to address the global namespace, which might allow $a ? ::foo() : ::bar() without parenthesis ? I don't know enough about the parser to say though. -- Jordi --- ## #40790 — jvlad — 2008-09-29T18:02:36+00:00 URL: https://externals.io/message/40711#40790 · In reply to: #40788 > > […] > > Will _you_ write such code? No. Will anybody from this list write such > code? You may want to write $a = $b?A:B:C and how would php compiler resolve A:B:C? A:B vs C or A vs B:C? To me it's better to stay with :: --- ## #40791 — johannes@php.net — 2008-09-29T18:08:32+00:00 URL: https://externals.io/message/40711#40791 · In reply to: #40788 > Monday 29 September 2008 18:35:45 Stefan Walk napisał(a): > > […] > > Will _you_ write such code? That's not the point. The point is the parser can't easily identify it - we barely care about namespaces, so someClass :: method ( ) ; is as valid as someClass::method(); independent from the context, same should be true for namespaces and their separator independent from the context. ... but well, that was all discussed multiple times before johannes --- ## #40804 — Arvids Godjuks — 2008-09-30T06:31:25+00:00 URL: https://externals.io/message/40711#40804 · In reply to: #40790 2008/9/29 jvlad > > […] > in > > […] > > You may want to write > $a = $b?A:B:C > and how would php compiler resolve A:B:C? > A:B vs C > or A vs B:C? > > To me it's better to stay with :: > > > > > -- > > > > We have (), so just do $a = $b ? (A:B:C:D) : blah(); Document, that namespaced calls should be in () with ternary operator and make it a parse error if coder forgets it. That's a good compromise and little to pay for namespaces, and doesn't break any BC. I think using ternary operator in such cases isn't realy wise - if () { } else {} is far more appropriate (anyway, I'l beat my coders for such usage of ternary operator). So as other members of this thread mentioned - would you really write code like this: $a = $b?A:B:C:D; Are you? Me 100% not. --- Next page: https://externals.io/message/40711.md?page=2