constructors with mix of params and Map

[Alex Tkachman]

Do we want to code like this where constructor params mixed with named
properties?

class Book {
  Book (String author, String coauthor) {
      this.author = author
      this.coauthor = coauthor
  }

  String title, author, coauthor
}

class SuperBook extends Book {
  SuperBook (Map map, String author, String coauthor) {
      super (author, coauthor)
      title = "SuperBook"
  }
}

class NewInstanceTest extends GroovyTestCase{
    void testNewInstance () {
       def book = Book.newInstance("Alex", title: "All about it", "Graeme" )
       assertEquals book.title, "All about it"
       assertEquals book.author, "Alex"
       assertEquals book.coauthor, "Graeme"
    }

    void testConstructor () {
       def book = new Book("Alex", title: "All about it", "Graeme" )
       assertEquals book.title, "All about it"
       assertEquals book.author, "Alex"
       assertEquals book.coauthor, "Graeme"
    }

    void testSuper () {
       def book = new SuperBook("Alex", title: "All about it", "Graeme" )
       assertEquals book.title, "SuperBook"
       assertEquals book.author, "Alex"
       assertEquals book.coauthor, "Graeme"
    }
}

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Alexandru Popescu ☀]

If we are looking for such features, I think Python system is the best
approach, and we should invent something in this field (it is usually
not allowed to mix location bound parameters with named parameters).

./alex
--
.w( the_mindstorm )p.


On 10/9/07, Alex Tkachman <alex.tkachman@...> wrote:

> Do we want to code like this where constructor params mixed with named
> properties?
>
> class Book {
>   Book (String author, String coauthor) {
>       this.author = author
>       this.coauthor = coauthor
>   }
>
>   String title, author, coauthor
> }
>
> class SuperBook extends Book {
>   SuperBook (Map map, String author, String coauthor) {
>       super (author, coauthor)
>       title = "SuperBook"
>   }
> }
>
> class NewInstanceTest extends GroovyTestCase{
>     void testNewInstance () {
>        def book = Book.newInstance("Alex", title: "All about it", "Graeme" )
>        assertEquals book.title, "All about it"
>        assertEquals book.author, "Alex"
>        assertEquals book.coauthor, "Graeme"
>     }
>
>     void testConstructor () {
>        def book = new Book("Alex", title: "All about it", "Graeme" )
>        assertEquals book.title, "All about it"
>        assertEquals book.author, "Alex"
>        assertEquals book.coauthor, "Graeme"
>     }
>
>     void testSuper () {
>        def book = new SuperBook("Alex", title: "All about it", "Graeme" )
>        assertEquals book.title, "SuperBook"
>        assertEquals book.author, "Alex"
>        assertEquals book.coauthor, "Graeme"
>     }
> }
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[glaforge]

Is there some reason (use case?) which triggered this idea?
Frankly, I'm not too fond of mixing maps and parameters too much.

On 10/9/07, Alex Tkachman <alex.tkachman@...> wrote:

> Do we want to code like this where constructor params mixed with named
> properties?
>
> class Book {
>   Book (String author, String coauthor) {
>       this.author = author
>       this.coauthor = coauthor
>   }
>
>   String title, author, coauthor
> }
>
> class SuperBook extends Book {
>   SuperBook (Map map, String author, String coauthor) {
>       super (author, coauthor)
>       title = "SuperBook"
>   }
> }
>
> class NewInstanceTest extends GroovyTestCase{
>     void testNewInstance () {
>        def book = Book.newInstance("Alex", title: "All about it", "Graeme" )
>        assertEquals book.title, "All about it"
>        assertEquals book.author, "Alex"
>        assertEquals book.coauthor, "Graeme"
>     }
>
>     void testConstructor () {
>        def book = new Book("Alex", title: "All about it", "Graeme" )
>        assertEquals book.title, "All about it"
>        assertEquals book.author, "Alex"
>        assertEquals book.coauthor, "Graeme"
>     }
>
>     void testSuper () {
>        def book = new SuperBook("Alex", title: "All about it", "Graeme" )
>        assertEquals book.title, "SuperBook"
>        assertEquals book.author, "Alex"
>        assertEquals book.coauthor, "Graeme"
>     }
> }
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Alexandru Popescu ☀]

On 10/9/07, Guillaume Laforge <glaforge@...> wrote:
> Is there some reason (use case?) which triggered this idea?
> Frankly, I'm not too fond of mixing maps and parameters too much.
>

Python supports the following format:

positional arguments
*args:
**args: named parameters

This seems to work oke there. But I don't think that mixing them makes sense.

./alex
--
.w( the_mindstorm )p.

> On 10/9/07, Alex Tkachman <alex.tkachman@...> wrote:
> > Do we want to code like this where constructor params mixed with named
> > properties?
> >
> > class Book {
> >   Book (String author, String coauthor) {
> >       this.author = author
> >       this.coauthor = coauthor
> >   }
> >
> >   String title, author, coauthor
> > }
> >
> > class SuperBook extends Book {
> >   SuperBook (Map map, String author, String coauthor) {
> >       super (author, coauthor)
> >       title = "SuperBook"
> >   }
> > }
> >
> > class NewInstanceTest extends GroovyTestCase{
> >     void testNewInstance () {
> >        def book = Book.newInstance("Alex", title: "All about it", "Graeme" )
> >        assertEquals book.title, "All about it"
> >        assertEquals book.author, "Alex"
> >        assertEquals book.coauthor, "Graeme"
> >     }
> >
> >     void testConstructor () {
> >        def book = new Book("Alex", title: "All about it", "Graeme" )
> >        assertEquals book.title, "All about it"
> >        assertEquals book.author, "Alex"
> >        assertEquals book.coauthor, "Graeme"
> >     }
> >
> >     void testSuper () {
> >        def book = new SuperBook("Alex", title: "All about it", "Graeme" )
> >        assertEquals book.title, "SuperBook"
> >        assertEquals book.author, "Alex"
> >        assertEquals book.coauthor, "Graeme"
> >     }
> > }
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
>
>
> --
> Guillaume Laforge
> Groovy Project Manager
> http://glaforge.free.fr/blog/groovy
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Alex Tkachman]

Typical use case is "call constructor with parameters and then set properties"

On 10/9/07, Guillaume Laforge <glaforge@...> wrote:

> Is there some reason (use case?) which triggered this idea?
> Frankly, I'm not too fond of mixing maps and parameters too much.
>
> On 10/9/07, Alex Tkachman <alex.tkachman@...> wrote:
> > Do we want to code like this where constructor params mixed with named
> > properties?
> >
> > class Book {
> >   Book (String author, String coauthor) {
> >       this.author = author
> >       this.coauthor = coauthor
> >   }
> >
> >   String title, author, coauthor
> > }
> >
> > class SuperBook extends Book {
> >   SuperBook (Map map, String author, String coauthor) {
> >       super (author, coauthor)
> >       title = "SuperBook"
> >   }
> > }
> >
> > class NewInstanceTest extends GroovyTestCase{
> >     void testNewInstance () {
> >        def book = Book.newInstance("Alex", title: "All about it", "Graeme" )
> >        assertEquals book.title, "All about it"
> >        assertEquals book.author, "Alex"
> >        assertEquals book.coauthor, "Graeme"
> >     }
> >
> >     void testConstructor () {
> >        def book = new Book("Alex", title: "All about it", "Graeme" )
> >        assertEquals book.title, "All about it"
> >        assertEquals book.author, "Alex"
> >        assertEquals book.coauthor, "Graeme"
> >     }
> >
> >     void testSuper () {
> >        def book = new SuperBook("Alex", title: "All about it", "Graeme" )
> >        assertEquals book.title, "SuperBook"
> >        assertEquals book.author, "Alex"
> >        assertEquals book.coauthor, "Graeme"
> >     }
> > }
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
>
>
> --
> Guillaume Laforge
> Groovy Project Manager
> http://glaforge.free.fr/blog/groovy
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Brandon Smith]

Alexandru Popescu ☀ wrote:

Python supports the following format:

positional arguments
*args:
**args: named parameters

This seems to work oke there. But I don't think that mixing them makes sense.

Python is very explicit that **kwargs must be last and *args must be last (or second to last when **kwargs is last).

In Groovy it is possible to simulate some of the positional/named arguments that Python supports. For instance:

def mymethod(arg1, arg2, List args=[], Map kwargs=[:]) {
  println "arg1: $arg1, arg2: $arg2, args: $args, kwargs: $kwargs"
}

groovy> mymethod('hello', 'world')
arg1: hello, arg2: world, args: [], kwargs: [:]

groovy> mymethod('hello', 'world', ['from', 'list'])
arg1: hello, arg2: world, args: ["from", "list"], kwargs: [:]

groovy> mymethod('hello', 'world', ['from', 'list'], [from: 'kwargs'])
arg1: hello, arg2: world, args: ["from", "list"], kwargs: ["from":"kwargs"]

I don't have to explain to this list that this is accomplished by compiling the above method definition down to three methods but will do so to illustrate a point. The following signatures are generated in bytecode:

Object mymethod(Object arg1, Object arg2, List args, Map kwargs)
Object mymethod(Object arg1, Object arg2, List args)
Object mymethod(Object arg1, Object arg2)

Should the inverse of the spread operator (i.e. something akin to 'collect') be introduced for method/closure arguments? If spread is used in a method or closure argument definition, it indicates that it is optional (i.e. args=[], kwargs=[:]) and that the arguments are to be interpreted a certain way. 'Overflow' positional args are rounded up into a List and named args into a Map. For instance, borrowing from Python, could the following syntax (* for positional and ** for named arguments) be introduced that enable the subsequent method calls?

def mymethod(arg1, arg2, *args, **kwargs) { ... }

groovy> mymethod('hello', 'world')
arg1: hello, arg2: world, args: [], kwargs: [:]

groovy> mymethod('hello', 'world', 'from', 'list')
arg1: hello, arg2: world, args: ["from", "list"], kwargs: [:]

groovy> mymethod('hello', 'world', 'from', 'list', from: 'kwargs')
arg1: hello, arg2: world, args: ["from", "list"], kwargs: ["from":"kwargs"]

groovy> mymethod('hello', 'world', from: 'kwargs')
arg1: hello, arg2: world, args: [], kwargs: ["from":"kwargs"]

You'll note that the last example, without positional arguments, is not possible in the current Groovy simulation from above, because a method signature is not created that supports it.

[Russel Winder]

On Tue, 2007-10-09 at 20:47 +0200, Guillaume Laforge wrote:
> Is there some reason (use case?) which triggered this idea?
> Frankly, I'm not too fond of mixing maps and parameters too much.

The parameter passing of Python (positional parameters, default values,
named parameters, excess positionals, excess named) is extremely
flexible and allows methods to have a large number of parameters that
no-one ever cares about.  The graphics packages use this a lot.
However, it is core to Python but not to Java and Groovy.  I can see the
use case but not the way the original example was set out.  There need
to be ordering rules.

--
Russel.
====================================================
Dr Russel Winder                       t: [phone]
41 Buckmaster Road               m: [phone]
London SW11 1EN, UK              w: http://www.russel.org.uk/

[Aaron Digulla]

Quoting Alexandru Popescu ☀ <the.mindstorm.mailinglist@...>:

> On 10/9/07, Guillaume Laforge <glaforge@...> wrote:
>> Is there some reason (use case?) which triggered this idea?
>> Frankly, I'm not too fond of mixing maps and parameters too much.
>>
>
> Python supports the following format:
>
> positional arguments
> *args:
> **args: named parameters
>
> This seems to work oke there. But I don't think that mixing them makes sense.

You can't mix them in Python, either. The order must be:

- Normal parameters
- Keyword arguments (or arguments with default value).
- Argument lists
- Maps

In the code, this looks like so:

def f(arg, argWithDefault='default value', *args, **kw):
     print 'arg=%s, argWithDefault=%s, *args=%s, **kw=%s' % (str(arg),  
str(argWithDefault), str(args), str(kw))

Resolution:

- The first parameter is stored in "arg"
- If there is a second parameter, then the value is stored in  
"argWithDefault". If there isn't, "argWithDefault" has the value  
'default value'. Note: The value is evaluated once. If you say, for  
example, x=[] to define a list, all invocations of f() will be passed  
the same list instance.
- All other, unnamed arguments end up in *args which is a list
- All named arguments end up in the map **kw.

Examples:

f() -> Error, because arg is missing
f(1) -> arg=1, argWithDefault='default value', *args=[], **kw={}
f(1,2) -> arg=1, argWithDefault=2, *args=[], **kw={}
f(1,2,3) -> arg=1, argWithDefault=2, *args=[3], **kw={}
f(1,2,3,4) -> arg=1, argWithDefault=2, *args=[3,4], **kw={}
f(1,2,3,4, argWithDefault=5) -> Error: Value of argWithDefault is  
specified twice.
f(1,argWithDefault=5,2,3,4) -> Error: non-keyword arg after keyword arg
f(1,2,3,4,a=5) -> arg=1, argWithDefault=2, *args=(3, 4), **kw={'a': 5}

> ./alex
> --
> .w( the_mindstorm )p.
>
>> On 10/9/07, Alex Tkachman <alex.tkachman@...> wrote:
>> > Do we want to code like this where constructor params mixed with named
>> > properties?
>> >
>> > class Book {
>> >   Book (String author, String coauthor) {
>> >       this.author = author
>> >       this.coauthor = coauthor
>> >   }
>> >
>> >   String title, author, coauthor
>> > }
>> >
>> > class SuperBook extends Book {
>> >   SuperBook (Map map, String author, String coauthor) {
>> >       super (author, coauthor)
>> >       title = "SuperBook"
>> >   }
>> > }
>> >
>> > class NewInstanceTest extends GroovyTestCase{
>> >     void testNewInstance () {
>> >        def book = Book.newInstance("Alex", title: "All about it",  
>>  "Graeme" )
>> >        assertEquals book.title, "All about it"
>> >        assertEquals book.author, "Alex"
>> >        assertEquals book.coauthor, "Graeme"
>> >     }
>> >
>> >     void testConstructor () {
>> >        def book = new Book("Alex", title: "All about it", "Graeme" )
>> >        assertEquals book.title, "All about it"
>> >        assertEquals book.author, "Alex"
>> >        assertEquals book.coauthor, "Graeme"
>> >     }
>> >
>> >     void testSuper () {
>> >        def book = new SuperBook("Alex", title: "All about it", "Graeme" )
>> >        assertEquals book.title, "SuperBook"
>> >        assertEquals book.author, "Alex"
>> >        assertEquals book.coauthor, "Graeme"
>> >     }
>> > }
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe from this list please visit:
>> >
>> >     http://xircles.codehaus.org/manage_email
>> >
>> >
>>
>>
>> --
>> Guillaume Laforge
>> Groovy Project Manager
>> http://glaforge.free.fr/blog/groovy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Alexandru Popescu ☀]

On 10/10/07, Aaron Digulla <digulla@...> wrote:

> Quoting Alexandru Popescu ☀ <the.mindstorm.mailinglist@...>:
>
> > On 10/9/07, Guillaume Laforge <glaforge@...> wrote:
> >> Is there some reason (use case?) which triggered this idea?
> >> Frankly, I'm not too fond of mixing maps and parameters too much.
> >>
> >
> > Python supports the following format:
> >
> > positional arguments
> > *args:
> > **args: named parameters
> >
> > This seems to work oke there. But I don't think that mixing them makes sense.
>

That was exactly my point. The initial Groovy example was not under
fixed ordering rules, and I have argumented that we should use a fixed
order rule if we want to support this feature.

./alex
--
.w( the_mindstorm )p.

> You can't mix them in Python, either. The order must be:
>
> - Normal parameters
> - Keyword arguments (or arguments with default value).
> - Argument lists
> - Maps
>
> In the code, this looks like so:
>
> def f(arg, argWithDefault='default value', *args, **kw):
>      print 'arg=%s, argWithDefault=%s, *args=%s, **kw=%s' % (str(arg),
> str(argWithDefault), str(args), str(kw))
>
> Resolution:
>
> - The first parameter is stored in "arg"
> - If there is a second parameter, then the value is stored in
> "argWithDefault". If there isn't, "argWithDefault" has the value
> 'default value'. Note: The value is evaluated once. If you say, for
> example, x=[] to define a list, all invocations of f() will be passed
> the same list instance.
> - All other, unnamed arguments end up in *args which is a list
> - All named arguments end up in the map **kw.
>
> Examples:
>
> f() -> Error, because arg is missing
> f(1) -> arg=1, argWithDefault='default value', *args=[], **kw={}
> f(1,2) -> arg=1, argWithDefault=2, *args=[], **kw={}
> f(1,2,3) -> arg=1, argWithDefault=2, *args=[3], **kw={}
> f(1,2,3,4) -> arg=1, argWithDefault=2, *args=[3,4], **kw={}
> f(1,2,3,4, argWithDefault=5) -> Error: Value of argWithDefault is
> specified twice.
> f(1,argWithDefault=5,2,3,4) -> Error: non-keyword arg after keyword arg
> f(1,2,3,4,a=5) -> arg=1, argWithDefault=2, *args=(3, 4), **kw={'a': 5}
>
> > ./alex
> > --
> > .w( the_mindstorm )p.
> >
> >> On 10/9/07, Alex Tkachman <alex.tkachman@...> wrote:
> >> > Do we want to code like this where constructor params mixed with named
> >> > properties?
> >> >
> >> > class Book {
> >> >   Book (String author, String coauthor) {
> >> >       this.author = author
> >> >       this.coauthor = coauthor
> >> >   }
> >> >
> >> >   String title, author, coauthor
> >> > }
> >> >
> >> > class SuperBook extends Book {
> >> >   SuperBook (Map map, String author, String coauthor) {
> >> >       super (author, coauthor)
> >> >       title = "SuperBook"
> >> >   }
> >> > }
> >> >
> >> > class NewInstanceTest extends GroovyTestCase{
> >> >     void testNewInstance () {
> >> >        def book = Book.newInstance("Alex", title: "All about it",
> >>  "Graeme" )
> >> >        assertEquals book.title, "All about it"
> >> >        assertEquals book.author, "Alex"
> >> >        assertEquals book.coauthor, "Graeme"
> >> >     }
> >> >
> >> >     void testConstructor () {
> >> >        def book = new Book("Alex", title: "All about it", "Graeme" )
> >> >        assertEquals book.title, "All about it"
> >> >        assertEquals book.author, "Alex"
> >> >        assertEquals book.coauthor, "Graeme"
> >> >     }
> >> >
> >> >     void testSuper () {
> >> >        def book = new SuperBook("Alex", title: "All about it", "Graeme" )
> >> >        assertEquals book.title, "SuperBook"
> >> >        assertEquals book.author, "Alex"
> >> >        assertEquals book.coauthor, "Graeme"
> >> >     }
> >> > }
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe from this list please visit:
> >> >
> >> >     http://xircles.codehaus.org/manage_email
> >> >
> >> >
> >>
> >>
> >> --
> >> Guillaume Laforge
> >> Groovy Project Manager
> >> http://glaforge.free.fr/blog/groovy
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe from this list please visit:
> >>
> >>     http://xircles.codehaus.org/manage_email
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
> >
>
>
>
> --
> Aaron "Optimizer" Digulla a.k.a. Philmann Dark
> "It's not the universe that's limited, it's our imagination.
> Follow me and I'll show you something beyond the limits."
> http://www.pdark.de/
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

[Jochen Theodorou]

Alexandru Popescu ☀ schrieb:

> On 10/10/07, Aaron Digulla <digulla@...> wrote:
>> Quoting Alexandru Popescu ☀ <the.mindstorm.mailinglist@...>:
>>
>>> On 10/9/07, Guillaume Laforge <glaforge@...> wrote:
>>>> Is there some reason (use case?) which triggered this idea?
>>>> Frankly, I'm not too fond of mixing maps and parameters too much.
>>>>
>>> Python supports the following format:
>>>
>>> positional arguments
>>> *args:
>>> **args: named parameters
>>>
>>> This seems to work oke there. But I don't think that mixing them makes sense.
>
> That was exactly my point. The initial Groovy example was not under
> fixed ordering rules, and I have argumented that we should use a fixed
> order rule if we want to support this feature.

we already have one. named arguments are in a map in the first argument,
additional positional arguments can be used by a vargs part...

for example

def foo(named=[:], arg1, arg2, Object.. args) {}

well it is working only locally , because Groovy seems to have a little
problem that I have to fix first.. but anyway, that is how it could be used

bye blackdrag

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Aaron Digulla]

Jochen Theodorou schrieb:

>> That was exactly my point. The initial Groovy example was not under
>> fixed ordering rules, and I have argumented that we should use a fixed
>> order rule if we want to support this feature.
>
> we already have one. named arguments are in a map in the first argument,
> additional positional arguments can be used by a vargs part...
>
> for example
>
> def foo(named=[:], arg1, arg2, Object.. args) {}
>
> well it is working only locally , because Groovy seems to have a little
> problem that I have to fix first.. but anyway, that is how it could be used

Will this work:

args=[a:'x']
foo(args, 1,2)

? I.e. is "args" assigned to "named" in this case?

Also something I'd like to see: Default values for parameters:

def foo(named=[:], arg1, arg2=5, Object... args) {}

Implementation:

Internally, all parameters with default values will be passed via a
varargs part. If there alreay is a varargs part, then they are added at
the front of the varargs array which is automatically created.

If the varargs array has a type != Object, then internally it will be
Object and the original variable arguments are then copied into a new
array with the correct type. Example:

def foo(named=[:], arg1, arg2=5, String... args) {}

will be converted into:

Object foo(Map names, Object arg1, Object... _args) {
    // Handle arguments with default values
    Object arg2; // Use object since no type was specified
    if (_args.length > 0) {
        arg2 = _args[0];
    } else {
        arg2 = new Integer(5); // Maybe extract constant here
                               // (saves a few cycles)
    }

    // Create expected varargs
    int len = Math.min(0, _args.length - 1);
    String[] args = new String[len];
    System.arraycopy (_args, 1, args, 0, len);

    // Original code follows here
}

(from the top of my head but you get the idea).

Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Alexandru Popescu ☀]

On 10/14/07, Aaron Digulla <digulla@...> wrote:

> Jochen Theodorou schrieb:
>
> >> That was exactly my point. The initial Groovy example was not under
> >> fixed ordering rules, and I have argumented that we should use a fixed
> >> order rule if we want to support this feature.
> >
> > we already have one. named arguments are in a map in the first argument,
> > additional positional arguments can be used by a vargs part...
> >
> > for example
> >
> > def foo(named=[:], arg1, arg2, Object.. args) {}
> >
> > well it is working only locally , because Groovy seems to have a little
> > problem that I have to fix first.. but anyway, that is how it could be used
>
> Will this work:
>
> args=[a:'x']
> foo(args, 1,2)
>
> ? I.e. is "args" assigned to "named" in this case?
>
> Also something I'd like to see: Default values for parameters:
>
> def foo(named=[:], arg1, arg2=5, Object... args) {}
>
> Implementation:
>
> Internally, all parameters with default values will be passed via a
> varargs part. If there alreay is a varargs part, then they are added at
> the front of the varargs array which is automatically created.
>
> If the varargs array has a type != Object, then internally it will be
> Object and the original variable arguments are then copied into a new
> array with the correct type. Example:
>
> def foo(named=[:], arg1, arg2=5, String... args) {}
>
> will be converted into:
>
> Object foo(Map names, Object arg1, Object... _args) {
>     // Handle arguments with default values
>     Object arg2; // Use object since no type was specified
>     if (_args.length > 0) {
>         arg2 = _args[0];
>     } else {
>         arg2 = new Integer(5); // Maybe extract constant here
>                                // (saves a few cycles)
>     }
>
>     // Create expected varargs
>     int len = Math.min(0, _args.length - 1);
>     String[] args = new String[len];
>     System.arraycopy (_args, 1, args, 0, len);
>
>     // Original code follows here
> }
>
> (from the top of my head but you get the idea).
>
> Regards,
>
> --
> Aaron "Optimizer" Digulla a.k.a. Philmann Dark
> "It's not the universe that's limited, it's our imagination.
> Follow me and I'll show you something beyond the limits."
> http://www.pdark.de/

Python defines good rules for the ordering of default valued
parameters. I really think that before discussing anything in this
direction we should try to take a look at how Python is handling all
these cases.

./alex
--
.w( the_mindstorm )p.

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Andres Almiray]

+1 let the multiple crosspollination begin :)

Alexandru Popescu ☀ wrote:

On 10/14/07, Aaron Digulla <[e-mail]> wrote:
> Jochen Theodorou schrieb:
>
> >> That was exactly my point. The initial Groovy example was not under
> >> fixed ordering rules, and I have argumented that we should use a fixed
> >> order rule if we want to support this feature.
> >
> > we already have one. named arguments are in a map in the first argument,
> > additional positional arguments can be used by a vargs part...
> >
> > for example
> >
> > def foo(named=[:], arg1, arg2, Object.. args) {}
> >
> > well it is working only locally , because Groovy seems to have a little
> > problem that I have to fix first.. but anyway, that is how it could be used
>
> Will this work:
>
> args=[a:'x']
> foo(args, 1,2)
>
> ? I.e. is "args" assigned to "named" in this case?
>
> Also something I'd like to see: Default values for parameters:
>
> def foo(named=[:], arg1, arg2=5, Object... args) {}
>
> Implementation:
>
> Internally, all parameters with default values will be passed via a
> varargs part. If there alreay is a varargs part, then they are added at
> the front of the varargs array which is automatically created.
>
> If the varargs array has a type != Object, then internally it will be
> Object and the original variable arguments are then copied into a new
> array with the correct type. Example:
>
> def foo(named=[:], arg1, arg2=5, String... args) {}
>
> will be converted into:
>
> Object foo(Map names, Object arg1, Object... _args) {
>     // Handle arguments with default values
>     Object arg2; // Use object since no type was specified
>     if (_args.length > 0) {
>         arg2 = _args[0];
>     } else {
>         arg2 = new Integer(5); // Maybe extract constant here
>                                // (saves a few cycles)
>     }
>
>     // Create expected varargs
>     int len = Math.min(0, _args.length - 1);
>     String[] args = new String[len];
>     System.arraycopy (_args, 1, args, 0, len);
>
>     // Original code follows here
> }
>
> (from the top of my head but you get the idea).
>
> Regards,
>
> --
> Aaron "Optimizer" Digulla a.k.a. Philmann Dark
> "It's not the universe that's limited, it's our imagination.
> Follow me and I'll show you something beyond the limits."
> http://www.pdark.de/

Python defines good rules for the ordering of default valued
parameters. I really think that before discussing anything in this
direction we should try to take a look at how Python is handling all
these cases.

./alex
--
.w( the_mindstorm )p.

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Aaron Digulla]

Quoting Alexandru Popescu ☀ <the.mindstorm.mailinglist@...>:

>> Internally, all parameters with default values will be passed via a
>> varargs part. If there alreay is a varargs part, then they are added at
>> the front of the varargs array which is automatically created.
>> [...]
> Python defines good rules for the ordering of default valued
> parameters. I really think that before discussing anything in this
> direction we should try to take a look at how Python is handling all
> these cases.

I think we are already past this point; I explained exactly how the  
argument order is defined in Python. Now, I'm looking at the  
implementation.

I would like to avoid a solution which creates N methods (where N is  
the number of params with default values), hence my idea of using  
varargs.

Another issue is mapping "direct" and "compiled" calls (a direct call  
is where you build the arguments yourself, i.e. the maps and arrays,  
and compiled calls is where the compiler takes source code and  
generates the correct all for you). In Python, you have call() and  
apply() for the former so Python can always distinguish between these  
cases:

def foo(named=[:], arg1, arg2=5, Object... args) {}

args=[a:'x']
foo(args, 1, 2, [])

Does the user mean "named=args, arg1=1, arg2=2, args=[]" or  
"named=[:], arg1=args, arg2=1, args=[2, []]"?

In Python, it's the second case and I suggest to handle this the same  
in Groovy, because there will be insane corner cases otherwise. If a  
user needs to build the function arguments manually (building a map in  
the code, etc), then they should use a special keyword to say "take  
this literally and don't try to map my arguments".

Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Aaron Digulla schrieb:

> Jochen Theodorou schrieb:
>
>>> That was exactly my point. The initial Groovy example was not under
>>> fixed ordering rules, and I have argumented that we should use a fixed
>>> order rule if we want to support this feature.
>> we already have one. named arguments are in a map in the first argument,
>> additional positional arguments can be used by a vargs part...
>>
>> for example
>>
>> def foo(named=[:], arg1, arg2, Object.. args) {}
>>
>> well it is working only locally , because Groovy seems to have a little
>> problem that I have to fix first.. but anyway, that is how it could be used
>
> Will this work:
>
> args=[a:'x']
> foo(args, 1,2)
>
> ? I.e. is "args" assigned to "named" in this case?

since it is the first argument, yes.... well, should. As soon as I fixed
the error in finding the method it is.

> Also something I'd like to see: Default values for parameters:
>
> def foo(named=[:], arg1, arg2=5, Object... args) {}

we already have that.

> Implementation:
>
> Internally, all parameters with default values will be passed via a
> varargs part. If there alreay is a varargs part, then they are added at
> the front of the varargs array which is automatically created.

I know you said you want to have this without creating multiple methods,
but that is the way Groovy currently does make it work. If you have:

def foo(a=3){}

you get two methods, one taking an Object, and one taking no Object, but
calling the other method with the value 3. vargs are a different
concept, I am not sure we should mix that together here.

> If the varargs array has a type != Object, then internally it will be
> Object and the original variable arguments are then copied into a new
> array with the correct type. Example:
>
> def foo(named=[:], arg1, arg2=5, String... args) {}
>
> will be converted into:
>
> Object foo(Map names, Object arg1, Object... _args) {
>     // Handle arguments with default values
>     Object arg2; // Use object since no type was specified
>     if (_args.length > 0) {
>         arg2 = _args[0];
>     } else {
>         arg2 = new Integer(5); // Maybe extract constant here
>                                // (saves a few cycles)
>     }
>
>     // Create expected varargs
>     int len = Math.min(0, _args.length - 1);
>     String[] args = new String[len];
>     System.arraycopy (_args, 1, args, 0, len);
>
>     // Original code follows here
> }
>
> (from the top of my head but you get the idea).

may I ask why you do not want to have multiple methods?

bye blackdrag

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Aaron Digulla]

Jochen Theodorou schrieb:

> may I ask why you do not want to have multiple methods?

While I wrote this, I was thinking that this may cause a N! explosion of
methods. The question is: How do you handle a method call like this:

def f(a1=1, a2=2, a3=3) {}

f(a2=5)

?

It should call f() with (1, 5, 3).

Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email