Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » RE: substr/array_slice in [] »

RE: substr/array_slice in []

php.internals

Ford, Mike [LSS]

18 years ago
On 01 October 2007 13:46, Antony Dovgal wrote:
> On 01.10.2007 16:32, Ilia Alshanetsky wrote: > > 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

Antony Dovgal

18 years ago
On 01.10.2007 21:39, Ford, Mike wrote:
> On 01 October 2007 13:46, Antony Dovgal wrote: > >> On 01.10.2007 16:32, Ilia Alshanetsky wrote: >> > 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

Stanislav Malyshev

18 years ago
> 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

Andrei Zmievski

18 years ago
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:

Stanislav Malyshev

18 years ago
> 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