Default Parameters Values

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Default Parameters Values

Nicolas Cannasse
Hi list,

I'm trying to clarify a bit the usage of default parameters values.

function foo( x = 1, y = "def" ) {
}

So far, while foo() result was consistent across platforms, there was
some differences between foo("") and foo(null,"").

Some platforms were accepting "null" as "use the default value", some
others as "null is manually specified, so use it instead of default value".

In order to make things more consistent and follow the "mostly expected
behavior", I'm planning to make theses changes :

- passing "null" will always set the value to "null", whatever the
default value

- in order to take advantage of platforms that support natively default
arguments (such as PHP and Flash9) but that doesn't have a way to force
the default value to be used, we will forbid argument-skipping such as
foo(""). Manually generating foo(1,"") in that case is not possible
because the foo method might be overriden/implemented with a different
default value, leading to hard-to-understand bugs.

What do you think ?

Best,
Nicolas



--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Default Parameters Values

jlm@justinfront.net
Nicolas

Sorry not really completely following, will this have any impact on  
tricks where you can use "?" to allow dealing with two types for  
instance...

public static function xmlAttTo_String( ?xml_: XML, ?xml2_: XMLList,  
str: String ): String
     {

         return if( xml_!=null ) xml_.attribute( str ).toString() else  
xml2_.attribute( str ).toString();

     }

Which I am sure can be improved, but allows dealing with tricky XML  
content where XML and XMLList are sort of interchangeable but not...

Cheers

;j


On 18 Dec 2010, at 11:24, Nicolas Cannasse wrote:

> Hi list,
>
> I'm trying to clarify a bit the usage of default parameters values.
>
> function foo( x = 1, y = "def" ) {
> }
>
> So far, while foo() result was consistent across platforms, there  
> was some differences between foo("") and foo(null,"").
>
> Some platforms were accepting "null" as "use the default value",  
> some others as "null is manually specified, so use it instead of  
> default value".
>
> In order to make things more consistent and follow the "mostly  
> expected behavior", I'm planning to make theses changes :
>
> - passing "null" will always set the value to "null", whatever the  
> default value
>
> - in order to take advantage of platforms that support natively  
> default arguments (such as PHP and Flash9) but that doesn't have a  
> way to force the default value to be used, we will forbid argument-
> skipping such as foo(""). Manually generating foo(1,"") in that case  
> is not possible because the foo method might be overriden/
> implemented with a different default value, leading to hard-to-
> understand bugs.
>
> What do you think ?
>
> Best,
> Nicolas
>
>
>
> --
> haXe - an open source web programming language
> http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Default Parameters Values

Nicolas Cannasse
Le 18/12/2010 12:41, [hidden email] a écrit :

> Nicolas
>
> Sorry not really completely following, will this have any impact on
> tricks where you can use "?" to allow dealing with two types for
> instance...
>
> public static function xmlAttTo_String( ?xml_: XML, ?xml2_: XMLList,
> str: String ): String
> {
>
> return if( xml_!=null ) xml_.attribute( str ).toString() else
> xml2_.attribute( str ).toString();
>
> }
>
> Which I am sure can be improved, but allows dealing with tricky XML
> content where XML and XMLList are sort of interchangeable but not...

We could still allow it in that case, since both XML and XMLList cannot
have a default value other than null. The issue is more with basic
types, as a consequence of allowing default values for them.

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Default Parameters Values

Heinz Hölzer-2
In reply to this post by Nicolas Cannasse
Are there any situations where overriding with a different default value
is usefull?

I would prefer to disallow overriding a method with different default
values.



Am 18.12.2010 11:24, schrieb Nicolas Cannasse:

> Hi list,
>
> I'm trying to clarify a bit the usage of default parameters values.
>
> function foo( x = 1, y = "def" ) {
> }
>
> So far, while foo() result was consistent across platforms, there was
> some differences between foo("") and foo(null,"").
>
> Some platforms were accepting "null" as "use the default value", some
> others as "null is manually specified, so use it instead of default
> value".
>
> In order to make things more consistent and follow the "mostly
> expected behavior", I'm planning to make theses changes :
>
> - passing "null" will always set the value to "null", whatever the
> default value
>
> - in order to take advantage of platforms that support natively
> default arguments (such as PHP and Flash9) but that doesn't have a way
> to force the default value to be used, we will forbid
> argument-skipping such as foo(""). Manually generating foo(1,"") in
> that case is not possible because the foo method might be
> overriden/implemented with a different default value, leading to
> hard-to-understand bugs.
>
> What do you think ?
>
> Best,
> Nicolas
>
>
>


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Default Parameters Values

Cauê W.
BTW Nicolas, is there any way to differentiate on the haXe source code (ocaml) between a null value passed as a parameter and a default parameter function? There should be, but I loooked quite a lot without much success. On C# I'm using a special Nulll<T> struct that could make a difference between a "with value" null and a "value less" null ; )

Cheers!
Caue

2010/12/18 Heinz Hölzer <[hidden email]>
Are there any situations where overriding with a different default value is usefull?

I would prefer to disallow overriding a method with different default values.



Am 18.12.2010 11:24, schrieb Nicolas Cannasse:

Hi list,

I'm trying to clarify a bit the usage of default parameters values.

function foo( x = 1, y = "def" ) {
}

So far, while foo() result was consistent across platforms, there was some differences between foo("") and foo(null,"").

Some platforms were accepting "null" as "use the default value", some others as "null is manually specified, so use it instead of default value".

In order to make things more consistent and follow the "mostly expected behavior", I'm planning to make theses changes :

- passing "null" will always set the value to "null", whatever the default value

- in order to take advantage of platforms that support natively default arguments (such as PHP and Flash9) but that doesn't have a way to force the default value to be used, we will forbid argument-skipping such as foo(""). Manually generating foo(1,"") in that case is not possible because the foo method might be overriden/implemented with a different default value, leading to hard-to-understand bugs.

What do you think ?

Best,
Nicolas





--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Default Parameters Values

Cauê W.

2010/12/18 Heinz Hölzer <[hidden email]>

Are there any situations where overriding with a different default value is usefull?

I would prefer to disallow overriding a method with different default values.

I agree..

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Default Parameters Values

Heinz Hölzer-2
And it's also misleading if you are dealing with an interface:

interface A {
    public function doIt(?a:String = "one"):Void;
}

class B implements A {
    public function new () {}
    public function doIt(?a:String = "two"):Void {
        trace(a);
    }
}

@before
class Main
{
    static function getMyA ():A {
        return new B();
    }
    static function main()
    {
        var a = getMyA();
       
        // here i would expect the default value "one" is passed, but it's "two"
        a.doIt(); // two
       
       
    }
}

Am 18.12.2010 15:16, schrieb Cauê Waneck:

2010/12/18 Heinz Hölzer <[hidden email]>

Are there any situations where overriding with a different default value is usefull?

I would prefer to disallow overriding a method with different default values.

I agree..


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Default Parameters Values

Nicolas Cannasse
In reply to this post by Heinz Hölzer-2
Le 18/12/2010 13:20, Heinz Hölzer a écrit :
> Are there any situations where overriding with a different default value
> is usefull?
>
> I would prefer to disallow overriding a method with different default
> values.

Not as easy at is sounds.

If you have an interface, you'ld have to specify the default value in
the interface as well. And you could not anymore alias your class
instance to { function foo(?x:Int) : Int } because the default value
would be erased.

In short : if the default value becomes part of the function type, then
it will create an additional constraint wrt subtyping rules.

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Default Parameters Values

Nicolas Cannasse
In reply to this post by Cauê W.
Le 18/12/2010 15:10, Cauê Waneck a écrit :
> BTW Nicolas, is there any way to differentiate on the haXe source code
> (ocaml) between a null value passed as a parameter and a default
> parameter function? There should be, but I loooked quite a lot without
> much success. On C# I'm using a special Nulll<T> struct that could make
> a difference between a "with value" null and a "value less" null ; )

Check typer.ml unify_call_params : some platforms use "undefined" as the
default value instead of "null".

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Default Parameters Values

Gamehaxe
In reply to this post by Nicolas Cannasse
Hi,
I have never been a fan of skipping args based on type, so I
will not be sorry to see the feature go.
However, named args may be useful if you are changing things ? eg:  
foo(y:"def")

If "null is null" then how do you do reflective calls - or do you go by
the number of args in the calling array, since you can now.
Still, it might be a bit tricky.

I think your proposed changes will probably simplify the c++ target a bit.

Hugh




> Hi list,
>
> I'm trying to clarify a bit the usage of default parameters values.
>
> function foo( x = 1, y = "def" ) {
> }
>
> So far, while foo() result was consistent across platforms, there was  
> some differences between foo("") and foo(null,"").
>
> Some platforms were accepting "null" as "use the default value", some  
> others as "null is manually specified, so use it instead of default  
> value".
>
> In order to make things more consistent and follow the "mostly expected  
> behavior", I'm planning to make theses changes :
>
> - passing "null" will always set the value to "null", whatever the  
> default value
>
> - in order to take advantage of platforms that support natively default  
> arguments (such as PHP and Flash9) but that doesn't have a way to force  
> the default value to be used, we will forbid argument-skipping such as  
> foo(""). Manually generating foo(1,"") in that case is not possible  
> because the foo method might be overriden/implemented with a different  
> default value, leading to hard-to-understand bugs.
>
> What do you think ?
>
> Best,
> Nicolas
>
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Default Parameters Values

Tarwin Stroh-Spijer
I think for people writing libraries it will make things a little harder to make easy to use APIs. I guess you could end up having a lot of checking code after your method ie:

function doThing(?a:String = "Hello", ?b:Int = -1)
{
  if (a == null) a = "Hello";
  if (b == 0) b = -1;
}

Or something like that. Will that still work? Will the compiler complain about having default values in the method signature? Am I getting this all wrong ?


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: +61 3 8060 5321
_______________________


On Tue, Dec 21, 2010 at 1:24 AM, Hugh Sanderson <[hidden email]> wrote:
Hi,
I have never been a fan of skipping args based on type, so I
will not be sorry to see the feature go.
However, named args may be useful if you are changing things ? eg:  foo(y:"def")

If "null is null" then how do you do reflective calls - or do you go by
the number of args in the calling array, since you can now.
Still, it might be a bit tricky.

I think your proposed changes will probably simplify the c++ target a bit.

Hugh





Hi list,

I'm trying to clarify a bit the usage of default parameters values.

function foo( x = 1, y = "def" ) {
}

So far, while foo() result was consistent across platforms, there was some differences between foo("") and foo(null,"").

Some platforms were accepting "null" as "use the default value", some others as "null is manually specified, so use it instead of default value".

In order to make things more consistent and follow the "mostly expected behavior", I'm planning to make theses changes :

- passing "null" will always set the value to "null", whatever the default value

- in order to take advantage of platforms that support natively default arguments (such as PHP and Flash9) but that doesn't have a way to force the default value to be used, we will forbid argument-skipping such as foo(""). Manually generating foo(1,"") in that case is not possible because the foo method might be overriden/implemented with a different default value, leading to hard-to-understand bugs.

What do you think ?

Best,
Nicolas



--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Default Parameters Values

Fei Yin
=====   Hello.hx ====
package;

class Hello
{
    static function main()
    {
        new Hello();
    }

    function new(?aaa:Int=3)
    {
        trace("Hello Wrold!" + Std.string(aaa));
    }
}

==== build.hxml ====
-neko neko/hello.n
-main Hello

--next
-php php
-main Hello

--next
-js js/hello.js
-main Hello

--next
-swf swf/hello.swf
-swf-version 9
-main Hello

--next
-cpp cpp
-main Hello


This was OK in haxe 2.06, all target working well . So you can just
define the default parameters value using

function foo(?param1:String = "value")


----
Best regards

Yin Fei

>From Icebirds.net



2010/12/21 Tarwin Stroh-Spijer <[hidden email]>:

> I think for people writing libraries it will make things a little harder to
> make easy to use APIs. I guess you could end up having a lot of checking
> code after your method ie:
> function doThing(?a:String = "Hello", ?b:Int = -1)
> {
>   if (a == null) a = "Hello";
>   if (b == 0) b = -1;
> }
> Or something like that. Will that still work? Will the compiler complain
> about having default values in the method signature? Am I getting this all
> wrong ?
>
>
> Tarwin Stroh-Spijer
> _______________________
>
> Touch My Pixel
> http://www.touchmypixel.com/
> phone: +61 3 8060 5321
> _______________________
>
>
> On Tue, Dec 21, 2010 at 1:24 AM, Hugh Sanderson <[hidden email]>
> wrote:
>>
>> Hi,
>> I have never been a fan of skipping args based on type, so I
>> will not be sorry to see the feature go.
>> However, named args may be useful if you are changing things ? eg:
>>  foo(y:"def")
>>
>> If "null is null" then how do you do reflective calls - or do you go by
>> the number of args in the calling array, since you can now.
>> Still, it might be a bit tricky.
>>
>> I think your proposed changes will probably simplify the c++ target a bit.
>>
>> Hugh
>>
>>
>>
>>
>>> Hi list,
>>>
>>> I'm trying to clarify a bit the usage of default parameters values.
>>>
>>> function foo( x = 1, y = "def" ) {
>>> }
>>>
>>> So far, while foo() result was consistent across platforms, there was
>>> some differences between foo("") and foo(null,"").
>>>
>>> Some platforms were accepting "null" as "use the default value", some
>>> others as "null is manually specified, so use it instead of default value".
>>>
>>> In order to make things more consistent and follow the "mostly expected
>>> behavior", I'm planning to make theses changes :
>>>
>>> - passing "null" will always set the value to "null", whatever the
>>> default value
>>>
>>> - in order to take advantage of platforms that support natively default
>>> arguments (such as PHP and Flash9) but that doesn't have a way to force the
>>> default value to be used, we will forbid argument-skipping such as foo("").
>>> Manually generating foo(1,"") in that case is not possible because the foo
>>> method might be overriden/implemented with a different default value,
>>> leading to hard-to-understand bugs.
>>>
>>> What do you think ?
>>>
>>> Best,
>>> Nicolas
>>>
>>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Default Parameters Values

Nicolas Cannasse
In reply to this post by Nicolas Cannasse
Le 18/12/2010 11:24, Nicolas Cannasse a écrit :
> - passing "null" will always set the value to "null", whatever the
> default value

For the record : this change that was applied in November to haXe SVN
was reverted. It causes too much backward compatibility issues without
helping much with crossplatformability.

I will make more tests and try to find a good balance between usability
and reusability ;)

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Default Parameters Values

Nicolas Cannasse
In reply to this post by Nicolas Cannasse
Le 18/12/2010 11:24, Nicolas Cannasse a écrit :
> - in order to take advantage of platforms that support natively default
> arguments (such as PHP and Flash9) but that doesn't have a way to force
> the default value to be used, we will forbid argument-skipping such as
> foo(""). Manually generating foo(1,"") in that case is not possible
> because the foo method might be overriden/implemented with a different
> default value, leading to hard-to-understand bugs.

Follow up : after finding some good way to implement cross platform
behavior on flash9 - relying only on native support for not-nullable
basic types - I decided to drop this change proposal.

Passing "null" will now always use the default value if one is
specified. This was 2.06 behavior on all platforms, and will be fixed in
2.07 for Flash9 only.

Please note that the variable still needs to be nullable to accept an
explicit "null" on Flash9 :

function foo(x=5) {}
foo(null); // error

Your need to declare foo as :

function foo(x:Null<Int>=5) {}

As for arguments skipping, haXe will still allow it since there's not
real reason to do otherwise so far.

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Default Parameters Values

Hudson Ansley
fwiw, I'm glad this proposal has been dropped. Passing null in flash9
and not getting the default was a source of annoyance to me, so very
happy you could work this out and have HaXe keep this advantage in
syntax sanity :-)
Regards,
Hudson

On Tue, Dec 21, 2010 at 8:33 AM, Nicolas Cannasse
<[hidden email]> wrote:
> Le 18/12/2010 11:24, Nicolas Cannasse a écrit :
>
> Follow up : after finding some good way to implement cross platform behavior
> on flash9 - relying only on native support for not-nullable basic types - I
> decided to drop this change proposal.
>

--
haXe - an open source web programming language
http://haxe.org