Hello Antony,
Saturday, October 6, 2007, 8:49:14 PM, you wrote:
> On 06.10.2007 22:38, Larry Garfield wrote:
>> I have no love for Perl (and a rather strong dislike of it), but I have to
>> agree with those who say that "looks like Perl" is a lame reason to reject
>> something. PHP's object sy
Most of the core developers were present at the PDM in Paris where that
item was put on the list.
-Andrei
Antony Dovgal wrote:
From what I understood, most of the core developers agreed that there are no
reasons to implement this syntax, so we're just wasting our time and traffic here.
--
operator is definitely easier because it lets us reuse the same syntax
for strings and arrays (and people would need to learn one operator
Having same syntax mean two different things (string access / array
access) doesn't qualify as "easy" in my book anyway. I know there's a
language which us
On 09/10/2007, Scott MacVicar <[EMAIL PROTECTED]> wrote:
> Sure it works fine when it's been in the language for several years and
> it's guaranteed to be available in the version provided by your hosting
> company.
>
> In reality this isn't the case with PHP so everyone will end up using
> the old
Sure it works fine when it's been in the language for several years and
it's guaranteed to be available in the version provided by your hosting
company.
In reality this isn't the case with PHP so everyone will end up using
the older method to support backwards compatibility or mixing it and
causin
Antony Dovgal wrote:
> Right, so let's force other people to learn crappy unreadable syntax
> duplicating nice and clear function call
Oddly, this "crappy unreadable syntax" doesn't lead to any confusion or
complaints for newbies of languages like python or ruby, judging from
the IRC channels. And
On 09.10.2007 12:48, Ford, Mike wrote:
>> Yes, I see this quite often in the list: "let's invent a new thing
>> instead of an old thing, that would make peoples' life easier".
>>
>> But you forget that both the old and the new thing would co-exist
>> and people would have to learn BOTH, which defi
On 09 October 2007 08:18, Antony Dovgal wrote:
> On 09.10.2007 10:57, Alexey Zakhlestin wrote:
> > > How come?
> > > It looks like you're reading $bar[':5'], but forgot the quotes.
> > > On the other side, what could be easier than a function call?
> >
> > operator is definitely easier because it
On 09.10.2007 10:57, Alexey Zakhlestin wrote:
>> How come?
>> It looks like you're reading $bar[':5'], but forgot the quotes.
>> On the other side, what could be easier than a function call?
>
> operator is definitely easier because it lets us reuse the same syntax
> for strings and arrays (and pe
On 10/9/07, Antony Dovgal <[EMAIL PROTECTED]> wrote:
> On 09.10.2007 06:32, Andrei Zmievski wrote:
> > I will use an example:
> >
> > $foo = substr($bar, 0, 5) . "-" . substr($bar, 5);
> >
> > or
> >
> > $foo = $bar[:5] . "-" . $bar[5:];
> >
> > I would argue that the second line is hardly more cry
On 09.10.2007 06:32, Andrei Zmievski wrote:
> I will use an example:
>
> $foo = substr($bar, 0, 5) . "-" . substr($bar, 5);
>
> or
>
> $foo = $bar[:5] . "-" . $bar[5:];
>
> I would argue that the second line is hardly more cryptic than the
> first one.
How come?
It looks like you're reading
I will use an example:
$foo = substr($bar, 0, 5) . "-" . substr($bar, 5);
or
$foo = $bar[:5] . "-" . $bar[5:];
I would argue that the second line is hardly more cryptic than the
first one. And if we were concerned that concerned about duplicate
functionality, we probably wouldn't have Simp
So what? Just because other languages implemented a good idea first
does not mean that it is verboten to us. PHP is result of years of
evolution (and yes, Terry, it's also a ball of nails) and stealing
ideas is one way to inject fresh genes into it.
-Andrei
On Oct 6, 2007, at 11:09 AM, Mar
On 08.10.2007 03:44, Rasmus Lerdorf wrote:
>> $result = $pdo->fetchAll(PDO::FETCH_ASSOC);
>> $result = array_combine(result[]['my_id'], $result);
>>
>> If I prepared a patch that made this possible, would it be considered
>> for inclusion? Is there any issues I've overlooked or other
>> objections
Emil Hernvall wrote:
> On a related note. Code like:
>
> $foo = array("a" => range(1,10), "b" => range(11,20));
> print_r($foo[][0]);
>
> results in
>
> Fatal error: Cannot use [] for reading in Command line code on line 3
>
> It would be incredibly useful when handling regular two-dimensional
On a related note. Code like:
$foo = array("a" => range(1,10), "b" => range(11,20));
print_r($foo[][0]);
results in
Fatal error: Cannot use [] for reading in Command line code on line 3
It would be incredibly useful when handling regular two-dimensional
database-resultsets. Essentially, what I'
On 06.10.2007 23:57, Alexey Zakhlestin wrote:
> I hardly find it too cryptic (it makes some array algorythms much more
> readable, actually)
Good for you.
> and in this case, having such construction would allow us to implement
> array_slice() in userland (which is not true other way round) ;)
I hardly find it too cryptic (it makes some array algorythms much more
readable, actually)
and in this case, having such construction would allow us to implement
array_slice() in userland (which is not true other way round) ;)
On 10/6/07, Antony Dovgal <[EMAIL PROTECTED]> wrote:
> On 06.10.2007 2
On 06.10.2007 22:38, Larry Garfield wrote:
> I have no love for Perl (and a rather strong dislike of it), but I have to
> agree with those who say that "looks like Perl" is a lame reason to reject
> something. PHP's object system looks an awful lot like Java, too. That
> doesn't make it bad.
I have no love for Perl (and a rather strong dislike of it), but I have to
agree with those who say that "looks like Perl" is a lame reason to reject
something. PHP's object system looks an awful lot like Java, too. That
doesn't make it bad.
"Too unreadable", "not approachable enough", "too
Hello Larry,
ArrayAccess is not designed to work in any array functions and we
explicitly decided against going that route. We wanted ArrayAccess to
support the array syntax, so [x,y] should be supported if we want that.
However I agree that this kind of slicing is a bit too perlish or
pythonish
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
On Thu, 4 Oct 2007, Larry Garfield wrote:
> On Tuesday 02 October 2007, Alexey Zakhlestin wrote:
> > On 10/1/07, Martin Alterisio <[EMAIL PROTECTED]> wrote:
> > > Sorry to bother, I have a few questions on this matter.
> > > How will this impact on the SPL ArrayAccess and related interfaces and
>
On 10/5/07, Larry Garfield <[EMAIL PROTECTED]> wrote:
> Here's the question I see. Right now, does an ArrayAccess object work with
> array_slice()? If so, then [2, 5] syntax would be just some nice syntactic
> sugar. If not, then it becomes a powerful new feature, and implementing it
> on norma
On Tuesday 02 October 2007, Alexey Zakhlestin wrote:
> On 10/1/07, Martin Alterisio <[EMAIL PROTECTED]> wrote:
> > Sorry to bother, I have a few questions on this matter.
> > How will this impact on the SPL ArrayAccess and related interfaces and
> > objects?
> > Will there be an interface to this f
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 k
2007/10/1, Antony Dovgal <[EMAIL PROTECTED]>:
> Yeah, too Perl-ish for me.
=) I dont see the need of implementing this either.
--
http://www.kissofjudas.net/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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.
Actually, it's a lot like Python list slicing, which is a great feature
and a clear enough sy
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
d
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.
>>
>
> Ple
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 comm
2007/10/2, Alexey Zakhlestin <[EMAIL PROTECTED]>:
>
> On 10/1/07, Martin Alterisio <[EMAIL PROTECTED]> wrote:
> > Sorry to bother, I have a few questions on this matter.
> > How will this impact on the SPL ArrayAccess and related interfaces and
> > objects?
> > Will there be an interface to this fu
On 10/1/07, Martin Alterisio <[EMAIL PROTECTED]> wrote:
> Sorry to bother, I have a few questions on this matter.
> How will this impact on the SPL ArrayAccess and related interfaces and
> objects?
> Will there be an interface to this functionality?
> If so, how will ranges be passed through to thi
Sorry to bother, I have a few questions on this matter.
How will this impact on the SPL ArrayAccess and related interfaces and
objects?
That's the problem with such syntax - one would expect it works with
ArrayAccess and it starts to be complicated...
--
Stanislav Malyshev, Zend Software Arch
Sorry to bother, I have a few questions on this matter.
How will this impact on the SPL ArrayAccess and related interfaces and
objects?
Will there be an interface to this functionality?
If so, how will ranges be passed through to this interface?
Will this be consistent with substr() and array_slice
It's on my TODO list.
-Andrei
Alexey Zakhlestin wrote:
Here http://www.php.net/~derick/meeting-notes.html#cleanup-for-vs is a
phrase "For both strings and arrays, the [] operator will support
substr()/array_slice() functionality"
will it appear in php5.x (php 5.3)?
--
PHP Internals - PHP R
Alexey Zakhlestin wrote:
Here http://www.php.net/~derick/meeting-notes.html#cleanup-for-vs is a
phrase "For both strings and arrays, the [] operator will support
substr()/array_slice() functionality"
will it appear in php5.x (php 5.3)?
I think since we do have substr/array_slice there's no nee
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.
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www
This was not on the table and the time of the 5.3 discussion, I for
one think its a bit too much magic.
On 1-Oct-07, at 7:30 AM, Alexey Zakhlestin wrote:
Here http://www.php.net/~derick/meeting-notes.html#cleanup-for-vs is a
phrase "For both strings and arrays, the [] operator will support
su
39 matches
Mail list logo
