This was not on the table and the time of the 5.3 discussion, I for
one think its a bit too much magic.Yeah, too Perl-ish for me.
Please stop this.
The minutes of the Paris meeting committed to implementing this for PHP 6, and it's a much-needed feature (IMHO, of course!). If you're going to start arguing against what looks very much like a firm decision of an eminent group of PHP core developers, you need much better reasons than "I don't like it" or "too like language x".
Cheers!
Mike
Mike Ford, Electronic Information Services Adviser,
JG125, The Headingley Library,
James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS, LS6 3QS, United Kingdom
Email: m.ford@leedsmet.ac.uk
Tel: +44 113 812 4730 Fax: +44 113 812 3211
To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm
This was not on the table and the time of the 5.3 discussion, I for
one think its a bit too much magic.Yeah, too Perl-ish for me.
Please stop this.
Stop what?
This is MY opinion, I can't help you if you don't like it.
The minutes of the Paris meeting committed to implementing this for PHP 6,
and it's a much-needed feature (IMHO, of course!).
I did not take part in this meeting, so I can agree or not with its results.
Also, from what I know, most of the people that made this decision have already changed their mind.
If you're going to start arguing
Argue? I'm going to do all I can to block such a useless feature.
I believe there are lots of much more important things to do than adding yet another syntax alias for substr().
against what looks very much like a firm
decision of an eminent group of PHP core developers, you need much better
reasons than "I don't like it" or "too like language x".
They were never meant to be "firm decisions".
As you can see, some of these "firm decisions" are already canceled.
--
Wbr,
Antony Dovgal
The minutes of the Paris meeting committed to implementing this for
PHP 6, and it's a much-needed feature (IMHO, of course!). If you're
Much needed for what? What can be done with it that can't be easily done
with other means?
going to start arguing against what looks very much like a firm
decision of an eminent group of PHP core developers, you need much
better reasons than "I don't like it" or "too like language x".
Here's much better reason: PHP is not the kitchen sink of features and
syntaxes. Not every cool idea belongs to core PHP. I am saying that this
particular feature definitely doesn't, but it needs to be proven that it
does. My opinion is that the same function is easily implemented by
existing means so adding this syntax is redundant.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
So it's okay to discuss implementation of esoteric features like class
posing, but something as basic as a string/array slice operation still
gets a knee-jerk reaction? Double standards my friends, double standards..
-Andrei
Stanislav Malyshev wrote:
Here's much better reason: PHP is not the kitchen sink of features and
syntaxes. Not every cool idea belongs to core PHP. I am saying that this
particular feature definitely doesn't, but it needs to be proven that it
does. My opinion is that the same function is easily implemented by
existing means so adding this syntax is redundant.
So it's okay to discuss implementation of esoteric features like class
posing, but something as basic as a string/array slice operation still
gets a knee-jerk reaction? Double standards my friends, double standards..
It's OK to discuss anything about PHP here, I guess. And if you like me
to be equal-opportunity knee-jerk-reactor, here it goes: I don't think
both of these two are really needed :) Now we can discuss...
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com