Re: [PHP-DEV] RFC: allow_call_pass_by_reference
On Wed, May 21, 2008 at 10:46 PM, LEW21 [EMAIL PROTECTED] wrote:
Sometimes call time pass by reference is useful, for example when you
want to make it possible to omit an param (normally passed by
reference) by setting null. With no call time pass by reference,
programmers are required to write:
$null = null;
foo($null);
what stops you from declaring:
function someFunc($param = null)
{
}
it works just fine
Deleting it isn't a good idea, it should become a normal (not
deprecated) language feature.
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: allow_call_pass_by_reference
Hi,
There is a use case for the function allowing *explicitly* call-time pass by
reference, because the function works both ways in subtly different ways.
I have some libraries where I had to have variations of the functions like
AbcByRefr() and Abc(), because of this inflexibility.
In a perfect world, here's how I'd do it, of course the actual syntax can be
something else (this also improves the understanding of the code as it makes
the intent explicit, versus implicit at call time, as it is now):
---
function foo( $a) {} // allows only explicit pass by reference
foo($a); // illegal, error
foo( $a); // legal, pass by reference
---
function bar($a) {} // forbids pass by reference
foo($a); // legal, pass as 'copy'
foo( $a); // illegal, error
---
function baz(? $a) {} // acknowledges that it functions properly and
accepts both ways
foo($a); // legal, pass as 'copy'
foo( $a); // legal, pass as reference
---
Regards,
Stan Vassilev
On Wed, May 21, 2008 at 10:46 PM, LEW21 [EMAIL PROTECTED] wrote:
Sometimes call time pass by reference is useful, for example when you
want to make it possible to omit an param (normally passed by
reference) by setting null. With no call time pass by reference,
programmers are required to write:
$null = null;
foo($null);
what stops you from declaring:
function someFunc($param = null)
{
}
it works just fine
Deleting it isn't a good idea, it should become a normal (not
deprecated) language feature.
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Short syntax for array literals [...]
On Thu, May 22, 2008 at 5:53 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote: Hi! $a = [[1, 2], [3, 4], 5, 6]; Proposed twice at least, but PHP developer community doesn't seem to like it. Many of us like it. And the end users I know like it too. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Short syntax for array literals [...]
On 22.05.2008 13:46, Pierre Joye wrote: On Thu, May 22, 2008 at 5:53 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote: Hi! $a = [[1, 2], [3, 4], 5, 6]; Proposed twice at least, but PHP developer community doesn't seem to like it. Many of us like it. And the end users I know like it too. I see no advantages here, only another way to do already possible thing and yet another way to confuse people. But starting this discussion from the very beginning makes very little sense. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode progress [Was: unicode.semantics ad infinitum]
Hey Andrei, UG(unicode) checks are still secondary I think - they don't prevent us from doing tests and moving forward, although cleaning them up would be nice. Cleaning them up would make it possible to find and fix the bugs we already know are there ;) There don't seem to be too many, but when it comes to tracking down conversions... bleh... pack() should take binary strings only, methinks. It does - 'UG(ascii_conv)' - but sometimes there's a unicode-to-binary conversion warning thrown by that, and then you have to cast the variable to a binary empty string to suppress the warning before you assign the pack() result to it. (See ext/phar/tests/phar_test.inc.) There are similar issues with unpack(), and with fwrite()/fread() and friends when dealing with a purely binary string. What concerns me at this point is that we could and should be telling PHP users how to future-proof their code during the move from PHP 4 to PHP 5. If we can get a fix on that now and get word out, we'll have made their future migration path *much* smoother. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Short syntax for array literals [...]
On Thu, May 22, 2008 at 11:56 AM, Antony Dovgal [EMAIL PROTECTED] wrote: On 22.05.2008 13:46, Pierre Joye wrote: On Thu, May 22, 2008 at 5:53 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote: Hi! $a = [[1, 2], [3, 4], 5, 6]; Proposed twice at least, but PHP developer community doesn't seem to like it. Many of us like it. And the end users I know like it too. I see no advantages here, only another way to do already possible thing and yet another way to confuse people. But starting this discussion from the very beginning makes very little sense. Agreed, we should simply go through a vote and be done with that. -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: allow_call_pass_by_reference
2008/5/22, Alexey Zakhlestin [EMAIL PROTECTED]:
On Wed, May 21, 2008 at 10:46 PM, LEW21 [EMAIL PROTECTED] wrote:
Sometimes call time pass by reference is useful, for example when you
want to make it possible to omit an param (normally passed by
reference) by setting null. With no call time pass by reference,
programmers are required to write:
$null = null;
foo($null);
what stops you from declaring:
function someFunc($param = null)
{
}
it works just fine
And what if this param isn't the last param of this function, and next
params are required?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: allow_call_pass_by_reference
On Thu, May 22, 2008 at 2:51 PM, LEW21 [EMAIL PROTECTED] wrote:
2008/5/22, Alexey Zakhlestin [EMAIL PROTECTED]:
On Wed, May 21, 2008 at 10:46 PM, LEW21 [EMAIL PROTECTED] wrote:
Sometimes call time pass by reference is useful, for example when you
want to make it possible to omit an param (normally passed by
reference) by setting null. With no call time pass by reference,
programmers are required to write:
$null = null;
foo($null);
what stops you from declaring:
function someFunc($param = null)
{
}
it works just fine
And what if this param isn't the last param of this function, and next
params are required?
Then I would say that is a bad design
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: allow_call_pass_by_reference
Hi,
Actually PHP ignores default values on parameters followed by required ones.
You can't fetch the default value even via Reflection.
This is easily detected at compile time so I wonder why the compiler doesn't
warn.
Regards,
Stan Vassilev
what stops you from declaring:
function someFunc($param = null)
{
}
it works just fine
And what if this param isn't the last param of this function, and next
params are required?
Then I would say that is a bad design
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: allow_call_pass_by_reference
Hi Stan, There is a use case for the function allowing *explicitly* call-time pass by reference, because the function works both ways in subtly different ways. This RFC isn't about whether or not this behaviour should be deprecated. It simply recommends that a warning be thrown by default in PHP 5.3 so that people will know to fix their code. The rationale for this is that there is ALWAYS a warning thrown in PHP 6, with no possibility to avoid that warning. It is also still marked deprecated in PHP 6, i.e. there is presumably a firm intention to remove the possibility for call-time pass-by-ref altogether. call_time_pass_by_reference behaviour has been deprecated for 8 years plus - since before the PHP 4.0 release. If you're writing code that relies on that behaviour, either you don't care about the warning or you've never seen it. I suspect rather a lot of PHP users have never seen it, because by default that warning isn't thrown at all. If you want to argue that there should be no warning by default, fine. But please try to stay on-topic. Thanks, - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Getting Default Values via reflection.
2008/5/22 Stan Vassilev | FM [EMAIL PROTECTED]:
Hi,
Actually PHP ignores default values on parameters followed by required ones.
You can't fetch the default value even via Reflection.
This is easily detected at compile time so I wonder why the compiler doesn't
warn.
Regards,
Stan Vassilev
I'm not sure this is what you mean, but I use the following function
in my debugging logic.
?php
function getArgs($s_Function, array $a_PassedParams = array()) {
$a_Arguments = array();
if ('' !== $s_Function) {
$rf_This = new ReflectionFunction($s_Function);
foreach($rf_This-getParameters() as $i_Param = $rp_Param) {
$a_Arguments[$rp_Param-getName()] = $i_Param
count($a_PassedParams) ? $a_PassedParams[$i_Param] :
$rp_Param-getDefaultValue() . ' (Default)';
}
}
return $a_Arguments;
}
function foo($required, $optional = 'snafu', $also_optional = 'sins') {
print_r(getArgss(__FUNCTION__, func_get_args()));
}
foo('fred');
foo('bob', 'jim');
outputs ...
Array
(
[required] = fred
[optional] = snafu (Default)
[also_optional] = sins (Default)
)
Array
(
[required] = bob
[optional] = jim
[also_optional] = sins (Default)
)
--
-
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
Standing on the shoulders of some very clever giants!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Short syntax for array literals [...]
Hi, On Thu, 2008-05-22 at 12:33 +0200, Pierre Joye wrote: Agreed, we should simply go through a vote and be done with that. Vote until all are annoyed and don't vote against it anymore just to stop voting? (it's less annoying to have it than vote about it every two months) There was some voting about this feature quite recently, don't have the archive link at hand. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Short syntax for array literals [...]
On Thu, May 22, 2008 at 3:56 PM, Johannes Schlüter [EMAIL PROTECTED] wrote: Hi, On Thu, 2008-05-22 at 12:33 +0200, Pierre Joye wrote: Agreed, we should simply go through a vote and be done with that. Vote until all are annoyed and don't vote against it anymore just to stop voting? (it's less annoying to have it than vote about it every two months) There was some voting about this feature quite recently, don't have the archive link at hand. Really? I missed the conclusion then. But if there was one, let begin to count. -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Getting Default Values via reflection.
Hi,
Please notice that I said followed by required ones.
function foo($a = null, $b) {}
The above definition is allowed and the compiler won't complain, but
actually that = null is completely lost, including in Reflection.
Regards,
Stan Vassilev
2008/5/22 Stan Vassilev | FM [EMAIL PROTECTED]:
Hi,
Actually PHP ignores default values on parameters followed by required
ones.
You can't fetch the default value even via Reflection.
This is easily detected at compile time so I wonder why the compiler
doesn't
warn.
Regards,
Stan Vassilev
I'm not sure this is what you mean, but I use the following function
in my debugging logic.
?php
function getArgs($s_Function, array $a_PassedParams = array()) {
$a_Arguments = array();
if ('' !== $s_Function) {
$rf_This = new ReflectionFunction($s_Function);
foreach($rf_This-getParameters() as $i_Param = $rp_Param) {
$a_Arguments[$rp_Param-getName()] = $i_Param
count($a_PassedParams) ? $a_PassedParams[$i_Param] :
$rp_Param-getDefaultValue() . ' (Default)';
}
}
return $a_Arguments;
}
function foo($required, $optional = 'snafu', $also_optional = 'sins') {
print_r(getArgss(__FUNCTION__, func_get_args()));
}
foo('fred');
foo('bob', 'jim');
outputs ...
Array
(
[required] = fred
[optional] = snafu (Default)
[also_optional] = sins (Default)
)
Array
(
[required] = bob
[optional] = jim
[also_optional] = sins (Default)
)
--
-
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
Standing on the shoulders of some very clever giants!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Short syntax for array literals [...]
On 22 May 2008, at 07:29, Pierre Joye wrote: On Thu, May 22, 2008 at 3:56 PM, Johannes Schlüter [EMAIL PROTECTED] wrote: Hi, On Thu, 2008-05-22 at 12:33 +0200, Pierre Joye wrote: Agreed, we should simply go through a vote and be done with that. Vote until all are annoyed and don't vote against it anymore just to stop voting? (it's less annoying to have it than vote about it every two months) There was some voting about this feature quite recently, don't have the archive link at hand. Really? I missed the conclusion then. But if there was one, let begin to count. Whether something is concluded or not is in the eye of the beholder... but it appears the conclusion here is: This is too much [unnecessary] magic: - http://php.markmail.org/message/k2xoyx5ql65vj6r6 Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Short syntax for array literals [...]
Hi! Many of us like it. And the end users I know like it too. You don't need to convince me :) -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode progress [Was: unicode.semantics ad infinitum]
Steph Fox wrote: What concerns me at this point is that we could and should be telling PHP users how to future-proof their code during the move from PHP 4 to PHP 5. If we can get a fix on that now and get word out, we'll have made their future migration path *much* smoother. As far as I can tell, it's effectively impossible for anyone who wants to support low PHP 5 versions. That's because the b prefix wasn't introduced until PHP 5.2.1, and that prefix is *crucial* to future-proofing any code that deals with binary data. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] magic quotes finale
[ forgot to sent that to the list ]
Hi Philip,
Am Dienstag, den 20.05.2008, 12:55 -0700 schrieb Philip Olson:
[...]
PHP 5.3 is approaching fast, so let's conclude our dealings with
magical quotes... this should be the last time. Please have a look at
the following RFC and discuss it within this thread.
Magic Quotes in PHP 5.3 and beyond
- http://wiki.php.net/rfc/magicquotes
It recommends changes to both 5_3 and 6_0 branches, namely, removing
E_DEPRECATED from the get_ magical quote functions. Silence means
you're okay with the RFC being implemented.
Why should we leave get_magic_quotes_gpc()? If someone wants to be
backwards compatible, just use
if (function_exists('get_magic_quotes_gpc') and @get_magic_quotes_gpc())
Let's just add this to the manual, and everything is fine.
I don't see a problem with this at all and it has the advantage of
allowing use to remove all the traces of magic quotes in 6. Magic quotes
are considered a bad practice for a long time.
cu, Lars
P.S.: Silence agrees doesn't work, silence is void.
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] magic quotes finale
cu, Lars P.S.: Silence agrees doesn't work, silence is void. Well, if silence is void: TAKE IT OFF!!! (+1 ... once again on this subject) -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Getting Default Values via reflection.
Hi,
Am Donnerstag, den 22.05.2008, 18:23 +0300 schrieb Stan Vassilev | FM:
[...]
function foo($a = null, $b) {}
Isn't that a typical case for throwing an E_STRICT warning or is is not
possible to check that efficiently in the engine?
cu, Lars
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] magic quotes finale
Hi David, Am Donnerstag, den 22.05.2008, 18:14 -0400 schrieb David Coallier: cu, Lars P.S.: Silence agrees doesn't work, silence is void. Well, if silence is void: TAKE IT OFF!!! (+1 ... once again on this #subject) You've spotted that the proposal is not about the question if they should be removed? It is about how to remove them :-) cu, Lars signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] magic quotes finale
Lars Strojny wrote:
[ forgot to sent that to the list ]
Hi Philip,
Am Dienstag, den 20.05.2008, 12:55 -0700 schrieb Philip Olson:
[...]
PHP 5.3 is approaching fast, so let's conclude our dealings with
magical quotes... this should be the last time. Please have a look at
the following RFC and discuss it within this thread.
Magic Quotes in PHP 5.3 and beyond
- http://wiki.php.net/rfc/magicquotes
It recommends changes to both 5_3 and 6_0 branches, namely, removing
E_DEPRECATED from the get_ magical quote functions. Silence means
you're okay with the RFC being implemented.
Why should we leave get_magic_quotes_gpc()? If someone wants to be
backwards compatible, just use
if (function_exists('get_magic_quotes_gpc') and @get_magic_quotes_gpc())
Let's just add this to the manual, and everything is fine.
I don't see a problem with this at all and it has the advantage of
allowing use to remove all the traces of magic quotes in 6. Magic quotes
are considered a bad practice for a long time.
We have covered this a bunch of times already. magic_quotes_gpc are
gone, but we leave in the function that tells userspace code that they
are off. get_magic_quotes_gpc() will always return false which means
that thousands of applications out there will run unchanged and will
simply take the magic_quotes off code path.
I see absolutely no reason to force people to go through and change:
if(!get_magic_quotes_gpc())
to:
if (!function_exists('get_magic_quotes_gpc') || !get_magic_quotes_gpc())
when there is no technical reason to force them to do so. It is slower,
more verbose and completely useless.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] magic quotes finale
PHP 5.3 is approaching fast, so let's conclude our dealings with
magical quotes... this should be the last time. Please have a look at
the following RFC and discuss it within this thread.
Magic Quotes in PHP 5.3 and beyond
- http://wiki.php.net/rfc/magicquotes
It recommends changes to both 5_3 and 6_0 branches, namely, removing
E_DEPRECATED from the get_ magical quote functions. Silence means
you're okay with the RFC being implemented.
Why should we leave get_magic_quotes_gpc()? If someone wants to be
backwards compatible, just use
if (function_exists('get_magic_quotes_gpc') and
@get_magic_quotes_gpc())
Let's just add this to the manual, and everything is fine.
We leave it because it's a developer friendly function that people
use. The checking of this feature is not deprecated, but rather, the
feature itself is deprecated and will be removed. And asking people to
update past and present code because we don't want the string
magic_quotes in php-src doesn't sound like much fun.
I don't see a problem with this at all and it has the advantage of
allowing use to remove all the traces of magic quotes in 6. Magic
quotes
are considered a bad practice for a long time.
That's why good developers check for it, and why we shouldn't punish
them for that. These E_* errors (and formally proposed removal
outright) equal punishment. Also note that magic_quotes_gpc is enabled
by default... even in PHP 5.3. So people have always checked for it,
and will continue to do so, and we already have get_magic_quotes_*()
so let's keep it with no E_rrors. Of course setting MQ is a totally
different story.
cu, Lars
P.S.: Silence agrees doesn't work, silence is void.
In this case all silence would have done is temporarily move the
conversation to [EMAIL PROTECTED]
Regards,
Philip
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] magic quotes finale
Hi Rasmus,
On Fri, May 23, 2008 at 1:35 AM, Rasmus Lerdorf [EMAIL PROTECTED] wrote:
Lars Strojny wrote:
[ forgot to sent that to the list ]
Hi Philip,
Am Dienstag, den 20.05.2008, 12:55 -0700 schrieb Philip Olson:
[...]
PHP 5.3 is approaching fast, so let's conclude our dealings with magical
quotes... this should be the last time. Please have a look at the following
RFC and discuss it within this thread.
Magic Quotes in PHP 5.3 and beyond
- http://wiki.php.net/rfc/magicquotes
It recommends changes to both 5_3 and 6_0 branches, namely, removing
E_DEPRECATED from the get_ magical quote functions. Silence means you're
okay with the RFC being implemented.
Why should we leave get_magic_quotes_gpc()? If someone wants to be
backwards compatible, just use
if (function_exists('get_magic_quotes_gpc') and @get_magic_quotes_gpc())
Let's just add this to the manual, and everything is fine.
I don't see a problem with this at all and it has the advantage of
allowing use to remove all the traces of magic quotes in 6. Magic quotes
are considered a bad practice for a long time.
We have covered this a bunch of times already. magic_quotes_gpc are gone,
but we leave in the function that tells userspace code that they are off.
get_magic_quotes_gpc() will always return false which means that thousands
of applications out there will run unchanged and will simply take the
magic_quotes off code path.
Exactly, what I said in my very first reply to this thread. With all
respects to Philip, this RFC and discussion are pointless, the
solution has been approved and the problem is about to be solved (when
I get two and half mins to apply my patch, probably early next week).
Cheers,
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] magic quotes finale
Hi,
Just making sure I understood it well. Get isn't deprecated (good), set is
(good), but what happens if I try to set magic quotes runtime *off* if it
was *on* from the config.
I couldn't see anything about the PHP config setting being ignored/removed
or throwing error in the RFC.
For code that must be portable, and I don't have access to server/PHP
config, I often have something like this in init:
if (get_magic_quotes_runtime()) {
set_magic_quotes_runtime(0);
}
if (get_magic_quotes_gpc()) {
include 'a_snippet_that_recursively_strips_slashes_off_gpc.php';
}
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Short syntax for array literals [...]
Not sure we really reached a conclusion. I think it was inconclusive and people got tired. As I've stated in the past in general I don't like the ability to do things in more than one way but in this case I think the advantages of the cleaner syntax outweigh the fact that we'd have two ways. I'd prefer to support [] but I don't think it's a huge deal if we don't do it. It would make PHP a bit nicer :) Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Short syntax for array literals [...]
Andi Gutmans wrote:
Not sure we really reached a conclusion. I think it was inconclusive and people
got tired.
As I've stated in the past in general I don't like the ability to do things in
more than one way but in this case I think the advantages of the cleaner syntax
outweigh the fact that we'd have two ways. I'd prefer to support [] but I don't
think it's a huge deal if we don't do it. It would make PHP a bit nicer :)
Andi
I almost typed it the other day not thinking. Been doing a lot of YUI
and {} and [] are growing on me.
+1
--
Brian Moon
Senior Developer/Engineer
--
When you care enough to spend the very least.
http://dealnews.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
