Re: [PHP-DEV] consistent way to handle structs

2002-01-14 Thread Hartmut Holzgraefe
Andi Gutmans wrote: > The alternative solution of allowing foo(,,4) would work and can probably > be implemented easier (it might still lead to a tiny slow down but > probably negligable); however it does look kind of ugly and it'll be quite > confusing if there will be lots of commas. functi

Re[2]: [PHP-DEV] consistent way to handle structs

2002-01-11 Thread Daniel Lorch
Hi, > There are two ways I can think of which would be sufficient solutions. The > first is the one you mention and the second is ADA style ability to > mention which argument is supposed to go to which parameter, e.g., foo(2 =>> two, 3 => three, 4 => four). [..] why not allow a construct like:

Re: [PHP-DEV] consistent way to handle structs

2002-01-11 Thread Andi Gutmans
On Fri, 11 Jan 2002 [EMAIL PROTECTED] wrote: > ** Reply to note from Markus Fischer <[EMAIL PROTECTED]> Fri, 11 Jan 2002 >12:48:15 +0100 > > > > What other way do we have to specify arbitray optional parameters > > without an ordering? Teh disadvantage of optional parmeters is when > > you nee

Re: [PHP-DEV] consistent way to handle structs

2002-01-11 Thread php4
** Reply to note from Markus Fischer <[EMAIL PROTECTED]> Fri, 11 Jan 2002 12:48:15 +0100 > > What other way do we have to specify arbitray optional parameters > without an ordering? Teh disadvantage of optional parmeters is when > you need to only set the last one, you'll have to define all >

Re: [PHP-DEV] consistent way to handle structs

2002-01-11 Thread Hartmut Holzgraefe
Darrell Brogdon wrote: > I think it would be a handy feature if someone got the urge to add it to > the spec. :) (hint.. hint...) think about the implications it would have on automatic typecasts as they are now ... -- PHP Development Mailing List To unsubscribe, e-mai

Re: [PHP-DEV] consistent way to handle structs

2002-01-11 Thread Darrell Brogdon
I think it would be a handy feature if someone got the urge to add it to the spec. :) (hint.. hint...) Zeev Suraski wrote: > At 04:36 PM 1/11/2002, Darrell Brogdon wrote: > >> I thought ZE2 was going to have support for method overloading? > > > Nope, it's not planned... > > Zeev > > -- Darr

Re: [PHP-DEV] consistent way to handle structs

2002-01-11 Thread Zeev Suraski
At 04:36 PM 1/11/2002, Darrell Brogdon wrote: >I thought ZE2 was going to have support for method overloading? Nope, it's not planned... Zeev -- PHP Development Mailing List To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To c

Re: [PHP-DEV] consistent way to handle structs

2002-01-11 Thread Darrell Brogdon
I thought ZE2 was going to have support for method overloading? Marc Boeren wrote: 7BE0F4A5D7AED2119B7500A0C94C58AC17ABFF@DELLSERVER"> [fn(foobar)] I agree on that. You really don't know which parameters itwas anymore.You don't have this problem with hashes.But

Re: [PHP-DEV] consistent way to handle structs

2002-01-11 Thread Andrei Zmievski
On Fri, 11 Jan 2002, Hartmut Holzgraefe wrote: > Andi Gutmans wrote: > > >... it'll encourage passing parameters in hashes which is something we > >really wouldn't want. > > > it is already common practice in userland so you are fighting > > a war that is already lost IMHO > > as soon as you

Re: [PHP-DEV] consistent way to handle structs

2002-01-11 Thread Andrei Zmievski
On Fri, 11 Jan 2002, Markus Fischer wrote: > I'm for (+1) assoc return values. > > I think the code which is used to handle it is more verbose > then ( $day = $assoc['day']; and not $day = $arr[0]; or > whatever) and it also helps debugging because you can just do > a print_r(

Re: [PHP-DEV] consistent way to handle structs

2002-01-11 Thread Andrey Hristov
ROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, January 11, 2002 2:43 PM Subject: RE: [PHP-DEV] consistent way to handle structs > > [fn(foobar)] > > I agree on that. You really don't know which parameters it > > was anymore.

Re: [PHP-DEV] consistent way to handle structs

2002-01-11 Thread Hartmut Holzgraefe
[EMAIL PROTECTED] wrote >>I cannot read code that looks like fn(foobar);, that is just a >>parameter-guessing-game! just that a feature may be misused can't be a reason against it IMHO > Of course, that looks likes crap, but one parameter not specified is not > a problem IMO. especi

Re: [PHP-DEV] consistent way to handle structs

2002-01-11 Thread Andi Gutmans
On Fri, 11 Jan 2002, Hartmut Holzgraefe wrote: > Andi Gutmans wrote: > > > ... it'll encourage passing parameters in hashes which is something we > > really wouldn't want. > > > it is already common practice in userland so you are fighting > > a war that is already lost IMHO Facts say it's n

RE: [PHP-DEV] consistent way to handle structs

2002-01-11 Thread Marc Boeren
[fn(foobar)] > I agree on that. You really don't know which parameters it > was anymore. > You don't have this problem with hashes. > But I already see this thread won't get us anywhere :) Well, I think everybody agrees that with hashes, functions are much easier to use..

Re: [PHP-DEV] consistent way to handle structs

2002-01-11 Thread derick
On Fri, 11 Jan 2002, Markus Fischer wrote: > On Fri, Jan 11, 2002 at 01:33:25PM +0100, Marc Boeren wrote : > > > > > make much sense to me. The current way suits fine, but maybe > > > this should be allowed too (as Hartmut wrote): function (foo,,bar); > > > > Please don't! > > I cannot read code

RE: [PHP-DEV] consistent way to handle structs

2002-01-11 Thread derick
On Fri, 11 Jan 2002, Marc Boeren wrote: > > > make much sense to me. The current way suits fine, but maybe > > this should be allowed too (as Hartmut wrote): function (foo,,bar); > > Please don't! > I cannot read code that looks like fn(foobar);, that is just a > parameter-guessing-game!

Re: [PHP-DEV] consistent way to handle structs

2002-01-11 Thread Markus Fischer
On Fri, Jan 11, 2002 at 01:33:25PM +0100, Marc Boeren wrote : > > > make much sense to me. The current way suits fine, but maybe > > this should be allowed too (as Hartmut wrote): function (foo,,bar); > > Please don't! > I cannot read code that looks like fn(foobar);, that is just a >

RE: [PHP-DEV] consistent way to handle structs

2002-01-11 Thread Marc Boeren
> make much sense to me. The current way suits fine, but maybe > this should be allowed too (as Hartmut wrote): function (foo,,bar); Please don't! I cannot read code that looks like fn(foobar);, that is just a parameter-guessing-game! Then again, that probably means that fn() is badly

Re: [PHP-DEV] consistent way to handle structs

2002-01-11 Thread Zak Greant
On 2002-11-01 04:51, Andi Gutmans wrote: > On Fri, 11 Jan 2002, Markus Fischer wrote: > > What other way do we have to specify arbitray optional > > parameters without an ordering? Teh disadvantage of optional > > parmeters is when you need to only set the last one, you'll > > have

Re: [PHP-DEV] consistent way to handle structs

2002-01-11 Thread derick
On Fri, 11 Jan 2002, Andi Gutmans wrote: > On Fri, 11 Jan 2002, Markus Fischer wrote: > > What other way do we have to specify arbitray optional > > parameters without an ordering? Teh disadvantage of optional > > parmeters is when you need to only set the last one, you'll > > hav

Re: [PHP-DEV] consistent way to handle structs

2002-01-11 Thread Hartmut Holzgraefe
Markus Fischer wrote: > What other way do we have to specify arbitray optional > parameters without an ordering? Teh disadvantage of optional > parmeters is when you need to only set the last one, you'll > have to define all preceding optional parameters too. well, the engine cou

Re: [PHP-DEV] consistent way to handle structs

2002-01-11 Thread Hartmut Holzgraefe
Andi Gutmans wrote: > ... it'll encourage passing parameters in hashes which is something we > really wouldn't want. it is already common practice in userland so you are fighting a war that is already lost IMHO as soon as you have, say, more then five parameters things get confusing, especial

Re: [PHP-DEV] consistent way to handle structs

2002-01-11 Thread Andi Gutmans
On Fri, 11 Jan 2002, Markus Fischer wrote: > What other way do we have to specify arbitray optional > parameters without an ordering? Teh disadvantage of optional > parmeters is when you need to only set the last one, you'll > have to define all preceding optional parameters too.

Re: [PHP-DEV] consistent way to handle structs

2002-01-11 Thread Markus Fischer
On Fri, Jan 11, 2002 at 12:58:44PM +0200, Andi Gutmans wrote : > On Fri, 11 Jan 2002, Markus Fischer wrote: > > > On Fri, Jan 11, 2002 at 11:22:22AM +0100, Hartmut Holzgraefe wrote : > > > Georg Richter wrote: > > > > > > >is there (should be) a consistent way to pass or return a structure?!

Re: [PHP-DEV] consistent way to handle structs

2002-01-11 Thread Andi Gutmans
On Fri, 11 Jan 2002, Markus Fischer wrote: > On Fri, Jan 11, 2002 at 11:22:22AM +0100, Hartmut Holzgraefe wrote : > > Georg Richter wrote: > > > > >is there (should be) a consistent way to pass or return a structure?! > > > > > >e.g.: > > > > > >a) Function mktime splits the structure in lot o

Re: [PHP-DEV] consistent way to handle structs

2002-01-11 Thread Markus Fischer
On Fri, Jan 11, 2002 at 11:22:22AM +0100, Hartmut Holzgraefe wrote : > Georg Richter wrote: > > >is there (should be) a consistent way to pass or return a structure?! > > > >e.g.: > > > >a) Function mktime splits the structure in lot of parameters > >b) fstat returns a non assoc array > >c) dio

Re: [PHP-DEV] consistent way to handle structs

2002-01-11 Thread Hartmut Holzgraefe
Georg Richter wrote: > is there (should be) a consistent way to pass or return a structure?! > > e.g.: > > a) Function mktime splits the structure in lot of parameters > b) fstat returns a non assoc array > c) dio_fstat (which seems to be identical to fstat) returns an assoc array assoc array

[PHP-DEV] consistent way to handle structs

2002-01-10 Thread Georg Richter
Hello, is there (should be) a consistent way to pass or return a structure?! e.g.: a) Function mktime splits the structure in lot of parameters b) fstat returns a non assoc array c) dio_fstat (which seems to be identical to fstat) returns an assoc array Georg -- PHP Development Mailing List