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
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:
- It's uber-contentious, and all the good stuff's only just starting to
turn up that would allow sane design decisions - 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
Hi!
Does that mean we can drop namespace support until 6.0?
Please?
Rationale:
- 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.
- 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
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
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
Steph Fox wrote:
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.
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:
<?php
namespace foo::bar;
class myclass {}
function myfunc()(}
var $myvar;
const myconst = 1;
?>
file 2:
<?php
include 'file1.php';
$a = new foo::bar::myclass;
foo::bar:>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:
- 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. - 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:
<?php
namespace http;
class Request {}
namespace http::request; // fatal error - name conflict between class
http::request and namespace http::request
class body {}
?>
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
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/
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 indeyets@gmail.comwrote:
On Sat, Sep 27, 2008 at 8:10 AM, Greg Beaver greg@chiaraquartet.net
wrote: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/
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
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
jvlad wrote:
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?
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
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
+1, or: "Do, or do not. There is no 'try.'"
- David
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
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.
+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
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
2008/9/29 Jordi Boggiano j.boggiano@seld.be
+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--
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:
<?php
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.
<?php
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.
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:
<?
print name1:name2?name3:name4:name5:name6;
/*
could mean:
$something?(namespace:namespace:constant) : (constant);
$something?(namespace:constant) : (namespace:constant);
and so on...
*/
?>
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:
<?
name1::name2();
/*
which could mean:
class::staticcall();
namespace::function();
and so on..
*/
?>
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 arvids.godjuks@gmail.comwrote:
2008/9/29 Jordi Boggiano j.boggiano@seld.be
On Mon, Sep 29, 2008 at 12:21 AM, Ryan Panning rpanning@gmail.com
wrote:+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--
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 viewFirstly I also proposed . as a separator, but it has issues with constants:
<?php
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.
<?php
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.
+1 for : from me.
Ternary. Operator. Trouble.
Otherwise it'd get my vote too.
- Steph
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;
Monday 29 September 2008 18:35:45 Stefan Walk napisał(a):
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;
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.
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;
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 ::
2008/9/29 jvlad dmda@yandex.ru
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;
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 ::
--
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.
In response to Larry Garfield's comment that "[t]here's nothing
"familiar" about :: to 99.99% of PHP developers who haven't already
been playing with the alphas" I'd like to point out that since PHP
5.1, the double colon is effectively used as a namespace operator by
extensions, in the sense that extensions started using class constants
instead of prefixed, global constants. e.g. PDO::PARAM_BOOL instead of
PDO_PARAM_BOOL.
Usage of class constants (or static methods, for that matter) as a way
to preserve the global namespace can also be seen in various projects
written in PHP.
Additionnally, I'd say there's some familiarity in considering that
classes, functions and constants are static members of a namespace the
same way that methods and constants can be static members of a class
but that may be subject to interpretation.
Monday 29 September 2008 18:35:45 Stefan Walk napisał(a):
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;
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
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;
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