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.
function
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 IMHO
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_fstat (which
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 of parameters
b)
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?!
e.g.:
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.
How
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, especialy
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 could
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
have to
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
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
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!
Of
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 that looks
[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...
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 not lost
[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.
especialy
: [PHP-DEV] consistent way to handle structs
[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
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() on
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 have, say,
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.
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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To
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
--
Darrell
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 http://www.php.net/
To unsubscribe, e-mail:
** 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
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 need to only
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:
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
27 matches
Mail list logo
