Hi all,
After speaking with several people about their todo items [1],
Johannes and I have settled on the 28th of August for the alpha2
release. We will package on the 27th. Seems like we have a good chance
for getting the open items completed by then.
Note that things that do not make it might get posponed to 5.3.1 (or
depending on the change even to the next minor/major version update).
Contrary to alpha1, where we were quite liberal in moving things to
alpha2, we will have to be more strict after alpha2. I know that its
always annoying if some feature gets delayed so long just because a
couple of days, but we must all remember that we have an endlessly
long feature list that is waiting to be released. So I hope that
everybody will find sufficient time to deal with their todo items
until alpha2. Please delegate to others early if you run into time
trouble.
As always please try to keep at least one RM in the loop about the
latest developments. This includes making sure we know that a given
item is done. We also hope that the inconsistencies thread will be
concluded in time to get any changes necessary applied.
Finally please remember to MFH (or MFB if you must) to save a bunny :)
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
After speaking with several people about their todo items [1],
Johannes and I have settled on the 28th of August for the alpha2
release. We will package on the 27th. Seems like we have a good
chance for getting the open items completed by then.
Sorry for the short notice.
I decided (I hope Johannes approves) to delay alpha2 until Tuesday
next week aka September 2nd. This step is taken in the hopes that the
additional time will mean we can skip doing an alpha3 and go straight
to beta1 before the end of September. Obviously a release in October
is now becoming quite tricky to say the least, but so it goes I guess.
Currently open are:
- GD (Pierre)
- ODBC patches (Derick)
- Fileinfo refactoring (Derick/Ilia/Mikko)
- Fileinfo tests (Derick/Felix)
- OpenSSL (Pierre)
- OpenLDAP (Pierre)
- Curly braces support for namespaces (Marcus, not ready for alpha2)
- Move ext/ming to PECL (Pierre)
Note that the Zend Signal Patch is no longer planned for 5.3. There
are currently too many open questions (ask Dmitry) and too many more
important things to spend our time on.
These items should be done no later than this Friday, so that we can
prepare things for a release on Tuesday for all platforms on Tuesday
without too much of a rush. Again we want to make sure that this
alpha2 release is solid enough that we can move into beta for the next
release.
Please keep us RMs in the loop about anything relevant that could
sabotage this plan.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
- Curly braces support for namespaces (Marcus, not ready for alpha2)
Why not? I thought I saw a patch for this on the list recently (which
allowed both the current namespace foo; and namespace foo {}
syntaxes)..
-Hannes
Hello Hannes,
Wednesday, August 27, 2008, 8:32:41 PM, you wrote:
- Curly braces support for namespaces (Marcus, not ready for alpha2)
Why not? I thought I saw a patch for this on the list recently (which
allowed both the current namespace foo; and namespace foo {}
syntaxes)..
It was an incomplete patch that simply allowed the syntax but did not
prevent code between two namespaces.
Best regards,
Marcus
Hello Marcus,
Em Qua, 2008-08-27 às 23:47 +0200, Marcus Boerger escreveu:
Hello Hannes,
Wednesday, August 27, 2008, 8:32:41 PM, you wrote:
- Curly braces support for namespaces (Marcus, not ready for alpha2)
Why not? I thought I saw a patch for this on the list recently (which
allowed both the current namespace foo; and namespace foo {}
syntaxes)..It was an incomplete patch that simply allowed the syntax but did not
prevent code between two namespaces.
That my old patch prevent the code between namespaces, but it only allow
the syntax using { }. Then, I've updated it, now it allows both ({}, ;)
Well, maybe it can be useful...
Results using the patch:
<?php
namespace a {
namespace b {
}
}
Fatal error: Nested namespace is not allowed in %s on line %d
<?php
namespace a {
namespace b;
}
Fatal error: Nested namespace is not allowed in %s on line %d
<?php
namespace a;
namespace b {}
namespace c;
print 1;
// OK, no error!
<?php
namespace a;
namespace b {}
print 1;
Fatal error: This script contains namespaces, all other code must be
contained within namespace declarations in %s on line %d
<?php
namespace a;
print 1;
namespace b {}
// OK, no error!
<?php
print 1;
namespace a;
Fatal error: Namespace declaration statement has to be the very first
statement in the script in %s on line %d
http://felipe.ath.cx/diff/namespace-braces-5_3.diff
--
Regards,
Felipe Pena.
Hello Marcus,
Em Qua, 2008-08-27 às 23:47 +0200, Marcus Boerger escreveu:
Hello Hannes,
Wednesday, August 27, 2008, 8:32:41 PM, you wrote:
- Curly braces support for namespaces (Marcus, not ready for alpha2)
Why not? I thought I saw a patch for this on the list recently (which
allowed both the current namespace foo; and namespace foo {}
syntaxes)..It was an incomplete patch that simply allowed the syntax but did not
prevent code between two namespaces.That my old patch prevent the code between namespaces, but it only allow
the syntax using { }. Then, I've updated it, now it allows both ({}, ;)Well, maybe it can be useful...
Results using the patch:
<?php
namespace a {
namespace b {
}
}
Fatal error: Nested namespace is not allowed in %s on line %d
I'm really sorry, but I have to ask.
Since you can detect that this is a nested namespace, why can't we allow it?
namespace foo {
class one {}
namespace bar {
class two {}
}
}
becomes class foo::one and class foo::bar::two ?
-Hannes
Hi!
I'm really sorry, but I have to ask.
Since you can detect that this is a nested namespace, why can't we allow it?
Because that's not how model was designed and it creates all kind of
trouble with name resolution. Basically, you get potentially infinite
resolution path. You don't want to go there. And frankly, there's
absolutely no need.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello Stanislav,
Thursday, August 28, 2008, 7:43:04 PM, you wrote:
Hi!
I'm really sorry, but I have to ask.
Since you can detect that this is a nested namespace, why can't we allow it?
Because that's not how model was designed and it creates all kind of
It wasn't designed to have multiple namespaces at all to begin with. But as
now have them we should at least think of what we want...
trouble with name resolution. Basically, you get potentially infinite
resolution path. You don't want to go there. And frankly, there's
absolutely no need.
How so?
namespace foo {
namespace bar {
class baz {}
}
}
According to your won words it is all about name substitution. Explicitly
you were talking about simple text replacement. Now that in mind I see and
easy replacement here. That is 'bar' becomes 'foo::bar' and 'baz' obviously
becomes 'foo::bar::baz' or can you find something else?
Actually we already have this:
namespace foo;
namespace foo::bar;
class baz {}
And that does exactly what I described above. But maybe I just to stupid
:-)
Best regards,
Marcus
Hi!
It wasn't designed to have multiple namespaces at all to begin with. But as
You mean multiple namespaces per file, right? Otherwise it sounds kind
of silly. Yes, it wasn't designed to have multiple namespaces per file,
and it's really bad idea to have multiple namespaces per file in 90% of
the cases. In the remaining 10% it's probably a bad idea too.
How so?
namespace foo {
namespace bar {
class baz {}
}
}According to your won words it is all about name substitution. Explicitly
you were talking about simple text replacement. Now that in mind I see and
No, it's not simple replacement, because hierarchy brings hierarchical
resolution, like it is in Ruby.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello Stanislav,
Friday, August 29, 2008, 7:53:02 PM, you wrote:
Hi!
It wasn't designed to have multiple namespaces at all to begin with. But as
You mean multiple namespaces per file, right? Otherwise it sounds kind
of silly. Yes, it wasn't designed to have multiple namespaces per file,
and it's really bad idea to have multiple namespaces per file in 90% of
the cases. In the remaining 10% it's probably a bad idea too.
How so?
namespace foo {
namespace bar {
class baz {}
}
}According to your won words it is all about name substitution. Explicitly
you were talking about simple text replacement. Now that in mind I see and
No, it's not simple replacement, because hierarchy brings hierarchical
resolution, like it is in Ruby.
Wasn't it you who said it is all about simple replacement?
However, you always said we shouldn't compare PHP features to other
languages and that for that reason we should not worry about the
keyword naming for instance. And that for the same reason we should
not take a specific implementation of another language. Why are you
suddenly taking Ruby's behavior as the thing to implement, if we
were going that route? [1]
But anyway, we seem to have to discuss the behavior in more detail.
For instance on 17th July Greg, who was very much involved in the
whole namespce implementation, summarized the open discussion points
and you simply turned the discussion dead immediately [2]. If people
constantly start mailing about issues they have, then we need to
address that or even get rid of the feature but we cannot say: this
is it, live with it as it is or not use it at all. None of that would
be the PHP way where we always have been trying to come to a simple
solution that works for everyone.
Personally, my take is that I don't need nesting but simply see it
as the natural thing to add. And text replacement, which is what the
current PHP implementation does, works pretty damn well for me. But
all I want is nested namespace and Felipe and I have a patch that
can hopefully be submitted during this weekend. Nesting or not does
not really matter to me. But seems to matter to other poeple. What
I totally disagree with, on the other hand, is namespaces without
curly braces - but that is no secret.
[1] http://marc.info/?l=php-internals&m=118728444125687&w=2
Quote: "PHP is neither C++ not Java. Choosing which language to
mimic - Java or C++ - is not the right way to think about the problem"
[2] http://marc.info/?l=php-internals&m=121627681216482&w=2
Quote: "OMG, not again... How many times should we talk about the same
thing?"
Best regards,
Marcus
Hi!
Wasn't it you who said it is all about simple replacement?
In current model, yes. With nesting in hierarchy, it ceases to be so,
that's exactly my point.
However, you always said we shouldn't compare PHP features to other
languages and that for that reason we should not worry about the
I didn't say that. I said that we should not take decisions based only
on the fact that other languages have it so. Of course we can look on
other languages and import whatever we feel is useful, however we should
not import stuff just because C++ and Java does so, contrary to how it
would work in PHP. PHP is its own language, and there's no obligation to
mimic any other one.
keyword naming for instance. And that for the same reason we should
not take a specific implementation of another language. Why are you
suddenly taking Ruby's behavior as the thing to implement, if we
were going that route? [1]
I definitely don't take Ruby's behavior, as Ruby's namespacing is
hierarchical, AFAIK.
For instance on 17th July Greg, who was very much involved in the
whole namespce implementation, summarized the open discussion points
and you simply turned the discussion dead immediately [2]. If people
I was and still am indeed somewhat sick of endless discussion about
braces and fixation on it. But OK, you won and we are having another 2
threads about it. I accept that and I again explained why I think it is
a bad idea - last time it was today. I think the positions on the braces
as syntax are more or less clear, and we all heard all arguments from
all sides multiple times, so I do not see much use in repeating them
over and over - unless you think I could explain something better or you
could bring some new idea, in which case I am ready to do what I can and
hear anything new anybody has to say.
constantly start mailing about issues they have, then we need to
address that or even get rid of the feature but we cannot say: this
I find it very disturbing that you again and again raise the question of
"getting rid of" namespaces - what are you trying to do? Why would you
want namespaces not exist in PHP?
is it, live with it as it is or not use it at all. None of that would
be the PHP way where we always have been trying to come to a simple
solution that works for everyone.
I did and do try to find the simplest solution possible ("possible" is
important here!). Having weird syntaxes and additions that have multiple
problems (like hierarchy) do not help. I try to accommodate as much
stuff people want as could be accomodated - namespaced functions (IMHO
abomination, but people wanted it - they got it), multiple files, etc.
But there has to be some conceptual integrity, otherwise it just turns
into a mess.
Personally, my take is that I don't need nesting but simply see it
as the natural thing to add. And text replacement, which is what the
As I explained, it is not natural addition - it makes the model much
more complex and resolution be O(N) instead of O(1). It also is not
appears to be useful for any practical purpose.
not really matter to me. But seems to matter to other people. What
OK, I would be happy to hear these other people - what are they use
cases and what they try to do with namespace nesting. Other people,
please speak.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
I'm really sorry, but I have to ask.
Since you can detect that this is a nested namespace, why can't we allow
it?Because that's not how model was designed and it creates all kind of trouble
with name resolution. Basically, you get potentially infinite resolution
path. You don't want to go there. And frankly, there's absolutely no need.
Seems like you are answering lot of questions about namespaces lately
with "that's not how the model was designed".
Guess it should have been designed in the open to begin with.
Thanks
-Hannes
Hi!
Seems like you are answering lot of questions about namespaces lately
with "that's not how the model was designed".
Not really, and it's not the reason, the reason why it wasn't designed
that way was explained before and was explained again.
Guess it should have been designed in the open to begin with.
It was. Just a lot of people couldn't care less until it is a day before
feature freeze and then they wake up and want whole thing rewritten from
scratch, and don't even take time to think about what their changes
really mean and how it is going to work with all other parts of the
language. Namespaces is not the only case btw.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello Stanislav,
Friday, August 29, 2008, 10:00:08 PM, you wrote:
Hi!
Seems like you are answering lot of questions about namespaces lately
with "that's not how the model was designed".
Not really, and it's not the reason, the reason why it wasn't designed
that way was explained before and was explained again.
Guess it should have been designed in the open to begin with.
It was. Just a lot of people couldn't care less until it is a day before
feature freeze and then they wake up and want whole thing rewritten from
scratch, and don't even take time to think about what their changes
really mean and how it is going to work with all other parts of the
language. Namespaces is not the only case btw.
Well partly right. No one cared when those several patches were developed.
Ever since one was finally submitted people tried to discuss the
implementation and behavioral differences. And you turned any discussion
attempt down for various reason. Like saying it was dicussed before, like
accusing people that they didn't care early enough and by saying that stuff
would be discussed once everything is finalized becasue apparently the
first submit wasn't supposed to be completely ready. Especially with that
in mind people were waiting for a hands up and starting adiscussion on the
finalized model from the developers. Nothing like that ever happened so all
people that weren't really happy could do nothing else then wait for alpha
releases which is the perfect time to experiement and figure out issues.
Actually even without any of the history of this particular feature in mind
- any new feature as big and as influentual as namespace has to be reviewed
and tried out in the alpha versions - that is why we have alpha versions
just as any other reasonable software application. But maybe you just want
to release what we have right now without any further testing periode and
have once again the end users suffer in production. Haven't we learned
anything, I thought we had.
Best regards,
Marcus
I think the majority of the namespaces stuff is fine. However, having
read the irc discussion about how the namespaces seperator was decided
upon, i don't think there are many people here who can honestly say
that ease of typing is that big of a deal compared to maintainability
and being able to easily read the code.
Both Perl and C++ use :: to success. i don't know how much of an
overlap there is in PHP and Perl or C++ programmers, so I'm not
suggesting it for familiarity reasons, but i have never heard anyone
say "i wish C++/ Perl used a different namespace separator.
Stas: I believe you work for Zend ? Have you tried going through ZF
and namespaced a few of the modules (using \ ) and then the code that
uses it ?
I tried to give it a go today with our framework internally and while
i know the '' has its merits, the code ( to us at least ) felt more
cluttered. I will continue to use it for a few weeks as I have done
C++ and Perl programming so familiarity might alter my perception.
Where you can use the 'use' statements, i will admit, its not that
bad. If you have alot of overlap with a 3rd parties code base and
'use' doesn't work so well then it becomes very difficult to read. At
least for my simple mind.
I know that you say the majority of people didn't 'care' up until now
but I feel thats untrue. The majority of people (I believe ) simply
thought that namespaces was heading in the right direction. I for one
was in this group although i have been mildly active on the list.
The old style long class names approach of ,
$bar = new Module_Name_Foo_Bar();
imho is more clear than
$bar = new Module\Name\Foo\Bar();
I still struggle to see how the :: is confusing or difficult to type.
$bar = new Module::Name::Foo::Bar();
Even if this was erroneous with syntax highlighting and the syntax
checker i really don't think its going to cause that much grief ( esp
given Perl / C++ ) have had it for a while.
is the below allowed ?
$bar = new Module \ Foo \ Bar();
I find it easier to read than with out the space.
i know with real namespaces you don't have to call the class Module_Foo_Bar
but i think a few people might be considering sticking with the long
classname approach.
Many of the PHP community as a whole been very supportive of everyone
working on the namespaces implemenation. There are a few vocal people
on this list but the majority I think are quite happy with what was
proposed previously. God knows we couldn't come up with a better
implementation but it would be nice if you could all remember that we
are using it day in day out as well. You have obviously seen how many
people 'care' now , and my guess is that it's largely because they
think this will have a big impact on their day to day use of the
language.
Since I haven't offered anything in the way of a solution yet, if i
were to write something that allowed the users to choose which
separator we used would that be considered ? If not, is it possible
that you could ( if its not already) make it trivial to change for
those of us who are willing to apply our own patches each time for our
particular machines. I don't think forking the project would achieve
much but it would be nice if I could maintain a small patchset which
could be applied to each release. That way those who want it can have
it.
I'm not saying that '' is a bad decision, They were all good reasons,
I'm simply saying that there are a significant number of users who
place a different priority on the reasons that those who made the
decision.
thank you for your time
Andrew
Hi!
Seems like you are answering lot of questions about namespaces lately
with "that's not how the model was designed".Not really, and it's not the reason, the reason why it wasn't designed that
way was explained before and was explained again.Guess it should have been designed in the open to begin with.
It was. Just a lot of people couldn't care less until it is a day before
feature freeze and then they wake up and want whole thing rewritten from
scratch, and don't even take time to think about what their changes really
mean and how it is going to work with all other parts of the language.
Namespaces is not the only case btw.Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Both Perl and C++ use :: to success. i don't know how much of an
overlap there is in PHP and Perl or C++ programmers, so I'm not
suggesting it for familiarity reasons, but i have never heard anyone
say "i wish C++/ Perl used a different namespace separator.
Yes, and as said multiple times: Using "::" is impossible and
alternatives were discussed multiple times, decision was made with
discussions over multiple years now.
So please let's move on and in a year or two we won't hear "anyone say
"i wish PHP used a different namespace separator""
Thanks for no further wasting of time. (neither yours nor mine, ...)
(except you find somethign which wasn't discussed within the last 5 yrs)
johannes
I found that he had one valid question that i would like to see answered.
is the below allowed ?
$bar = new Module \ Foo \ Bar();
I find it easier to read than with out the space.
Since it looks pretty good with the spaces there.
2008/10/27 Johannes Schlüter johannes@php.net:
Both Perl and C++ use :: to success. i don't know how much of an
overlap there is in PHP and Perl or C++ programmers, so I'm not
suggesting it for familiarity reasons, but i have never heard anyone
say "i wish C++/ Perl used a different namespace separator.Yes, and as said multiple times: Using "::" is impossible and
alternatives were discussed multiple times, decision was made with
discussions over multiple years now.So please let's move on and in a year or two we won't hear "anyone say
"i wish PHP used a different namespace separator""Thanks for no further wasting of time. (neither yours nor mine, ...)
(except you find somethign which wasn't discussed within the last 5 yrs)johannes
I found that he had one valid question that i would like to see answered.
is the below allowed ?
$bar = new Module \ Foo \ Bar();
I find it easier to read than with out the space.
Since it looks pretty good with the spaces there.
I don't see why it wouldn't be allowed. You can already do
function_name (), or classname :: methodname
().
This isn't python, the parser doesn't really care about the spaces :)
-Hannes
I found that he had one valid question that i would like to see answered.
is the below allowed ?
$bar = new Module \ Foo \ Bar();
I find it easier to read than with out the space.
Since it looks pretty good with the spaces there.
I don't see why it wouldn't be allowed. You can already do
function_name (), or classname :: methodname
().
This isn't python, the parser doesn't really care about the spaces :)
It might work in some places, not always, consider
<?php
$class = '\ foo \ bar \ baz';
new $class();
?>
as the name is stored without spaces in the class table, not sure
whether it's worth parsing whitespaces in such cases...
johannes
$class = '\ foo \ bar \ baz';
In those cases i get why its an issue. But when i look at:
namespace\class\method()
against
namespace \ class \ method()
I get the feeling that \ is a pretty good solution.
2008/10/27 Johannes Schlüter johannes@php.net:
I found that he had one valid question that i would like to see answered.
is the below allowed ?
$bar = new Module \ Foo \ Bar();
I find it easier to read than with out the space.
Since it looks pretty good with the spaces there.
I don't see why it wouldn't be allowed. You can already do
function_name (), or classname :: methodname
().
This isn't python, the parser doesn't really care about the spaces :)It might work in some places, not always, consider
<?php
$class = '\ foo \ bar \ baz';
new $class();
?>as the name is stored without spaces in the class table, not sure
whether it's worth parsing whitespaces in such cases...johannes
I found that he had one valid question that i would like to see answered.
is the below allowed ?
$bar = new Module \ Foo \ Bar();
Don't know i never saw something so ugly since c++ templates syntax
I find it funny that php is designed by committee and no one listen to
the community
And the team continues even if is an bad decision (they call it
technical one) if you see it from the point of view of syntax elegance
it's not so pretty even c++ looks better .
It doesn't make sense if you compare it with modern languages
and my vote is -1
[End of rant]
I find it easier to read than with out the space.
maybe it should be "/." and is quite easy to find it on the keyboardSince it looks pretty good with the spaces there.
2008/10/27 Johannes Schlüter johannes@php.net:
Both Perl and C++ use :: to success. i don't know how much of an
overlap there is in PHP and Perl or C++ programmers, so I'm not
suggesting it for familiarity reasons, but i have never heard anyone
say "i wish C++/ Perl used a different namespace separator.Yes, and as said multiple times: Using "::" is impossible and
alternatives were discussed multiple times, decision was made with
discussions over multiple years now.So please let's move on and in a year or two we won't hear "anyone say
"i wish PHP used a different namespace separator""Thanks for no further wasting of time. (neither yours nor mine, ...)
(except you find somethign which wasn't discussed within the last 5 yrs)johannes
--
--
--
developer flamerobin.org
Hi Marius,
Don't know i never saw something so ugly since c++ templates syntax
I find it funny that php is designed by committee and no one listen to
the community
You have written to this list a few times before. Here's a brief summary of
your posts:
- We should be moving to git not svn
- We should drop $ for variables because it makes PHP 'bloated'
- Mingw compilation (which we don't support) fails
- If we want your help supporting firebird under Windows we should build it
and send you a report - We're on slashdot (for )
===
And the team continues even if is an bad decision (they call it
technical one) if you see it from the point of view of syntax elegance
it's not so pretty even c++ looks better .
I'm not even going to comment on that.
- Steph
Hi Marius,
Don't know i never saw something so ugly since c++ templates syntax
I find it funny that php is designed by committee and no one listen to
the communityYou have written to this list a few times before. Here's a brief summary of
your posts:
- We should be moving to git not svn
- We should drop $ for variables because it makes PHP 'bloated'
- Mingw compilation (which we don't support) fails
- If we want your help supporting firebird under Windows we should build it
and send you a report- We're on slashdot (for )
===
And the team continues even if is an bad decision (they call it
technical one) if you see it from the point of view of syntax elegance
it's not so pretty even c++ looks better .I'm not even going to comment on that.
- Steph
yes is true that i like to have strong opinions and yes i could be
wrong in most of them
but when all the comunity screems at the namespace issue i think
core developers should be more diplomatic and offer the good solution not
close the eyes and wash the hands and go forward
an semisolution would be an php.ini variable
like
NAMSPACE_SEPARATOR="::"
so if you have an issue with your classes can be reset to "" or
whatever with ini_set
i think it's easy to be done if i look at the patch that created the
backslash separator issue
http://pear.php.net/~greg/backslash.sep.patch.txt
--
developer flamerobin.org
but when all the comunity screems at the namespace issue i think
core developers should be more diplomatic and offer the good
solution not
close the eyes and wash the hands and go forward
its always nice to ask for diplomacy after throwing around insults.
that being said, we have been quite calm in trying to explain the
reasons. but maybe if people would try out more reasonable forms of
inquiry it would all go a bit smoother, it takes two to tango.
at any rate, i hope that we will soon have a FAQ online that will make
it even easier (easier than reading through 3 RFC's on the wiki). not
sure when that will be ready.
an semisolution would be an php.ini variable
like
NAMSPACE_SEPARATOR="::"
so if you have an issue with your classes can be reset to "" or
whatever with ini_set
this will lead to incompatible code and deployment nightmares.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
2008/10/28 marius popa mapopa@gmail.com:
Hi Marius,
Don't know i never saw something so ugly since c++ templates syntax
I find it funny that php is designed by committee and no one listen to
the communityYou have written to this list a few times before. Here's a brief summary of
your posts:
- We should be moving to git not svn
- We should drop $ for variables because it makes PHP 'bloated'
- Mingw compilation (which we don't support) fails
- If we want your help supporting firebird under Windows we should build it
and send you a report- We're on slashdot (for )
===
And the team continues even if is an bad decision (they call it
technical one) if you see it from the point of view of syntax elegance
it's not so pretty even c++ looks better .I'm not even going to comment on that.
- Steph
yes is true that i like to have strong opinions and yes i could be
wrong in most of them
but when all the comunity screems at the namespace issue i think
core developers should be more diplomatic and offer the good solution not
close the eyes and wash the hands and go forwardan semisolution would be an php.ini variable
like
NAMSPACE_SEPARATOR="::"
so if you have an issue with your classes can be reset to "" or
whatever with ini_set
An ini value for a language operator? I don't think I know any
language that lets the end developers change the way a language looks
like by a configurative, and honestly that doesn't solve any issues if
someone uses :: as seperator unless :: is disabled.
i think it's easy to be done if i look at the patch that created the
backslash separator issue
http://pear.php.net/~greg/backslash.sep.patch.txt
Parts of the code is generated by RE2C so its not really as easy as it may look
--
developer flamerobin.org--
--
Kalle Sommer Nielsen
On Tuesday 28 October 2008 13:41:24 marius popa wrote:
an semisolution would be an php.ini variable
like
NAMSPACE_SEPARATOR="::"
so if you have an issue with your classes can be reset to "" or
whatever with ini_set
Please make this list readonly or at least moderated for non-devs (yes, that
includes me). This is getting ridiculous.
Regards,
Stefan
marius popa wrote:
an semisolution would be an php.ini variable
like
NAMSPACE_SEPARATOR="::"
so if you have an issue with your classes can be reset to "" or
whatever with ini_seti think it's easy to be done if i look at the patch that created the
backslash separator issue
So you're suggesting that part of PHP's syntax should be a
user-configurable option because you don't like the current solution?
How do you propose using code that requires the standard separator if
you change it? Or sharing code that uses a non-standard separator?
D
Dave Ingram wrote:
marius popa wrote:
an semisolution would be an php.ini variable
like
NAMSPACE_SEPARATOR="::"
so if you have an issue with your classes can be reset to "" or
whatever with ini_seti think it's easy to be done if i look at the patch that created the
backslash separator issueSo you're suggesting that part of PHP's syntax should be a
user-configurable option because you don't like the current solution?
How do you propose using code that requires the standard separator if
you change it? Or sharing code that uses a non-standard separator?
I apologise: I missed a golden opportunity for sarcasm there.
<sarcasm> Yeah! I've also never really liked some of the other operators... let's have:NAMESPACE_SEPARATOR="::"
STRING_CONCATENATOR="+"
OBJECT_ACCESSOR="."
</sarcasm>
I agree with Stefan. This really is getting silly. Although I'm not sure
that permanently moderating the list is necessarily the way to go. Maybe
until people calm down and accept what the devs and RMs have decided?
D
Hi Marius,
yes is true that i like to have strong opinions and yes i could be
wrong in most of them
but when all the comunity screems at the namespace issue
"All the community" is not screaming at the namespace issue. "A minority of
the community" is, but most of that minority would scream whatever we did.
an semisolution would be an php.ini variable
like
NAMSPACE_SEPARATOR="::"
:-)
Now go away and think really hard about what you wrote there, and you'll
maybe understand that smiley.
- Steph
Steph
You dismiss the vocal voices far to quickly, claiming its only a minority
against this is very misleading - The majority of Developers are probably
oblivious to this conversation.
The way this argument is heating up and people are being flamed downed,
Namespaces will be known as the "Addition that killed PHP" rather than the
"Killer addition to PHP".
I'm of the opinion that using a \ is a bad idea, mostly for the same reasons
as everybody else, and I think lots of people will avoid using them like the
plague.
Since this affects everybody, it should be opened up to the community, so,
the internals should put together several options and then open a poll for
the community to vote on and then use which ever comes out on top.
Cheers
Kelvin
""Steph Fox"" steph@php.net wrote in message
news:022101c938fc$a77cae50$3ffc1f3e@foxbox...
Hi Marius,
yes is true that i like to have strong opinions and yes i could be
wrong in most of them
but when all the comunity screems at the namespace issue"All the community" is not screaming at the namespace issue. "A minority
of the community" is, but most of that minority would scream whatever we
did.an semisolution would be an php.ini variable
like
NAMSPACE_SEPARATOR="::":-)
Now go away and think really hard about what you wrote there, and you'll
maybe understand that smiley.
- Steph
Since this affects everybody, it should be opened up to the community, so,
the internals should put together several options and then open a poll for
the community to vote on and then use which ever comes out on top.Cheers
Kelvin
This has been done so many times... I'm following this discussion in
probably the last 2 years, but as Steph mentioned womewhere it was ongoing
for the last 5. In the last month there were votings too.
According to the last discussions looks like the main candidates for ns
separators were '', ':::' and probably ':>'.
I think everyone (especially the core developers) is sick of discussing and
voting.
""Steph Fox"" steph@php.net wrote in message
news:022101c938fc$a77cae50$3ffc1f3e@foxbox...Hi Marius,
yes is true that i like to have strong opinions and yes i could be
wrong in most of them
but when all the comunity screems at the namespace issue"All the community" is not screaming at the namespace issue. "A minority
of the community" is, but most of that minority would scream whatever we
did.an semisolution would be an php.ini variable
like
NAMSPACE_SEPARATOR="::":-)
Now go away and think really hard about what you wrote there, and you'll
maybe understand that smiley.
- Steph
--
--
Vesselin Kenashkov
developer at
www.webstudiobulgaria.com
I really wish that this list was developer-only (which would mean i
couldn't write this post). The developers made a decision. And as much
as I dislike the "feel" of the '' as namespace separator, the
argumentation for it is really solid - and it's a one character,
distinctive separator. Would you all really prefer to have to stand on
your head and make funny gestures instead? I wouldn't.
In the end the users of this language will do as they have always done
with new features. 20% will dislike the implementation, 20% will
outward not use it and 10% will misunderstand the benefits. But the
rest of use will do as usual - adapt, and be glad for a new, and
useful improvement.
So, as one of the people waiting for this feature for last 4 or 5
years, please, go with it, ignore the whiners, and make as all happy,
as you continue to do :)
Oh, and come out with that alpha as soon as possible, I'm so eager to
try this out :)
Thanks,
Kamil "Brego" Dzielinski: http://brego.dk/
Life is ours, we live it our way -- Metallica
On Wednesday 29 October 2008 16:23:55 you wrote:
Since this affects everybody, it should be opened up to the community, so,
the internals should put together several options and then open a poll for
the community to vote on and then use which ever comes out on top.
And the winner is ...
:never_gonna_give_you_up:
personally I like ">>" but I'm pretty sure that wouldn't be possible ;)
"Stefan Walk" et@php.net wrote in message
news:200810291750.56475.et@php.net...
On Wednesday 29 October 2008 16:23:55 you wrote:
Since this affects everybody, it should be opened up to the community,
so,
the internals should put together several options and then open a poll
for
the community to vote on and then use which ever comes out on top.And the winner is ...
:never_gonna_give_you_up:
an semisolution would be an php.ini variable
like
NAMSPACE_SEPARATOR="::"
so if you have an issue with your classes can be reset to "" or
whatever with ini_set
You're always welcome to change the separator in the PHP source code,
compile that and use your fork as you please. The source code is the
ultimate PHP configuration ...
Regards, Stan Vassilev
marius popa wrote:
yes is true that i like to have strong opinions and yes i could be
wrong in most of them
but when all the comunity screems at the namespace issue i think
core developers should be more diplomatic and offer the good solution not
close the eyes and wash the hands and go forwardan semisolution would be an php.ini variable
like
NAMSPACE_SEPARATOR="::"
so if you have an issue with your classes can be reset to "" or
whatever with ini_seti think it's easy to be done if i look at the patch that created the
backslash separator issue
http://pear.php.net/~greg/backslash.sep.patch.txt
This thread has been scheduled for demolition by the Vogon Construction Fleet. You hae
less than 2 minutes remaining to vacate the thread. Have a nice day.
-Andrei