RE: Default parameter values for methods

Hello Mike,

I certainly agree that method overloading is a very useful mechanism,
and for more or less the same reasons.

Overloading is creating *different* methods with the same name, and
letting the compiler statically resolve the method reference of a call
based on number and types of the actual parameters. Parameter defaults
are a way to allow *the same* method to be called with different sets of
parameters.

I am not sure we are facing a choice between parameter defaults and
method overloading in e. I think they are complementary mechanisms that
can coexist (see for example C++). So at least in principle we may
choose to introduce method overloading down the road, regardless of
whether we have parameter defaults or not.

Here are a couple of reasons why I think method overloading in e is
problematic:

1. With overloading the types of the parameters become part of the
identity criteria for a method. In a language with a rich type system
and various automatic casting rules the semantics becomes quite
intricate (again consider C++). In e all numeric scalars are
type-compatible, and so are values of derived enumerated types.
Moreover, some literal values may be of different types depending on
context (e.g. 'NULL' may be object reference or string value). So in
many cases it becomes quite messy to tell which method is being called
(both for the programmer and the compiler...).

2. The fact that a method name is unique in the scope of a class
(struct/unit) is deeply rooted in various aspects of the language and
tools. Consider for example reflection API queries where the name serves
as the sole identity criterion for methods. This is also reflected in
different development utilities.

I think the above also gives an idea of why method overloading is a
project of a whole different scale, mostly for tool vendors, but also
for the standard committee. So I think it's not realistic to expect this
to be supported soon.

Matan.

>-----Original Message-----
>From: Mike TVS [mailto:mike@tandvsolns.co.uk]
>Sent: Friday, June 12, 2009 10:31 AM
>To: Matan Vax; Uwe Simm; ieee1647@eda.org
>Cc: 'Mike TVS'
>Subject: RE: Default parameter values for methods
>
>Hi Matan
>
>This sounds like a good idea to me - but in the interests of getting
the
>right decision I would like to debate this a little more relative to
>overloading (which I have always found VERY useful in my OO code in the
>past). So:
>
>- What are the advantages of default values over overloading?
>- What are the disadvantages of default values over overloading?
>- You say that overloading is complex to define and implement - can you
>expand why please?
>- Although you believe it is harder to define and implement - is it
harder
>for the programmer to use?
>
>Regards
>
>Mike
>
>-----Original Message-----
>From: owner-ieee1647@server.eda.org
[mailto:owner-ieee1647@server.eda.org]
>On Behalf Of Matan Vax
>Sent: 11 June 2009 11:00
>To: Uwe Simm; ieee1647@server.eda.org
>Subject: RE: Default parameter values for methods
>
>Hey Uwe,
>
>Thanks for these questions. Here is a first take:
>
>Default values must be compile-time constants so there is no specific
scope
>for their evaluation. This restrictive semantics is inline with other
>languages and easily covers most applications (variable defaults can
often
>be emulated procedurally once a constant default has been designated).
>
>It complicates the syntax of the language if we introduce empty
expressions
>as in "foo(,,,TRUE)". I see no reason to go beyond other languages on
this
>one. It's typically natural to order parameters of a method in such a
way
>that the ones with defaults are at the end in descending order of
>likelihood
>for overriding.
>
>Hope this makes sense to you.
>
>Matan.
>
>>-----Original Message-----
>>From: Uwe Simm
>>Sent: Thursday, June 11, 2009 12:34 PM
>>To: Matan Vax
>>Subject: FW: Default parameter values for methods
>>
>>hi matan,
>>
>>other important questions with default args are:
>>
>>- in what scope are expressions for default args computed ?
>>
>>- what are legal expressions for default args? are they compile time
>>constants, "elab" time const, instance const, fields?
>>
>>- do you also want default args supported in other position other than
>in
>>the tail of function args?
>>  something like "foo(,,,TRUE)" ?
>>
>>btw: i didnt post this one to the reflector but feel free to forward
>>
>>regards
>>/uwe
>>
>>
>>-----Original Message-----
>>From: owner-ieee1647@eda.org on behalf of Matan Vax
>>Sent: Thu 2009-06-11 09:28
>>To: darren.galpin@infineon.com; ieee1647@eda.org
>>Subject: RE: Default parameter values for methods
>>
>>Hey Darren,
>>
>>
>>
>>What I propose is simply to adopt the standard approach to default
>>parameters. The values provided in the method call get associated with
>>parameters simply in order from left to right. The types of the
>>expressions do not affect this strict in-order correlation (so a
>>parameter type mismatch is reported in the usual way). There is no way
>>to provide in a method call a value for a parameter without providing
>>values for all parameters preceding it. Similarly in a method
>>declaration if a parameter with default is followed by a parameter
>>without default a compile time error is issued.
>>
>>
>>
>>Following your code example:
>>
>>
>>
>>extend sys {
>>
>>    // this is the syntax I have in mind, similar to other languages
>>
>>   my_method(a: bool = TRUE, b: bool = FALSE) is {
>>
>>      // ...
>>
>>   };
>>
>>
>>
>>   run() is also {
>>
>>      my_method(); // the two defaults are used
>>
>>      my_method(FALSE); // the default for the first parameter is
>>overridden, the second is still used
>>
>>      my_method(FALSE,TRUE); // both defaults are overridden
>>
>>   };
>>
>>};
>>
>>
>>
>>Hope this clarifies things.
>>
>>Matan.
>>
>>
>>
>>________________________________
>>
>>From: darren.galpin@infineon.com [mailto:darren.galpin@infineon.com]
>>Sent: Thursday, June 11, 2009 9:47 AM
>>To: Matan Vax; ieee1647@eda.org
>>Subject: RE: Default parameter values for methods
>>
>>
>>
>>Hi Matan,
>>
>>
>>
>>It seems like a good idea, but I have a few questions about this, as I
>>may be misunderstanding a few things.
>>
>>
>>
>>Firstly, you have a method, such as:-
>>
>>
>>
>>a: default=TRUE; -- An example, syntax will obviously be different
>>
>>b: default=FALE; -- As above.
>>
>>my_method(a: bool, b: bool) {
>>
>>};
>>
>>
>>
>>Normally you would then call the method as follows:-
>>
>>
>>
>>my_method(TRUE, FALSE);
>>
>>
>>
>>Which is fine, but if you do not provide all of the parameters, then
>>what happens in the following case:-
>>
>>
>>
>>my_method(FALSE);
>>
>>
>>
>>Which of the two boolean parameters have I set, and which of the two
>>have I missed? It isn't clear to me from the description how this
would
>>operate.
>>
>>
>>
>>Perhaps others could comment? Should we include it?
>>
>>
>>
>>Cheers,
>>
>>
>>
>>Darren
>>
>>
>>
>>________________________________
>>
>>From: owner-ieee1647@server.eda.org
>>[mailto:owner-ieee1647@server.eda.org] On Behalf Of Matan Vax
>>Sent: Wednesday, June 10, 2009 6:54 PM
>>To: ieee1647@server.eda.org
>>Subject: Default parameter values for methods
>>
>>Hello all,
>>
>>
>>
>>As you probably know, many object-oriented languages allow declaring
>>default values for method parameters. Specifically in our domain both
>>SystemC (C++) and SystemVerilog support it. The principle is simple -
>if
>>a default value is designated for some parameter in the method
>>declaration providing the parameter in the call becomes optional. If
>>provided, the user's parameter overrides the default, and otherwise
the
>>default is passed to the method body. Upon method call parameters are
>>resolved in order, so all parameters with defaults must be placed at
>the
>>end of the parameter list.
>>
>>
>>
>>This mechanism can be used to simplify functional APIs of core
>>libraries, verification IPs, and other packages. When introducing some
>>operation, library designers often face the dilemma of either defining
>a
>>single method and forcing the user to provide all possible parameters,
>>including trivial ones (NULL, UNDEF, 0, or whatever the natural
default
>>happens to be), or defining multiple method variants with different
>>parameter sets, each with its own name. Both obscure the natural
>>semantics of the operation. Note that method overloading may have
>>similar impact, but is much more complicated to define and implement.
>>
>>
>>
>>So I propose we consider adding this capability to the e standard (and
>>obviously implement it in tools, Specman in particular). Defining it
>>formally is relatively straightforward and I volunteer to do it if I
>get
>>green light from this forum.
>>
>>
>>
>>What do you say?
>>
>>Matan.
>>
>>
>>
>>
>>--
>>This message has been scanned for viruses and dangerous content by
>>MailScanner <http://www.mailscanner.info/> , and
>is
>>
>>believed to be clean.
>>
>>
>>--
>>This message has been scanned for viruses and dangerous content by
>>MailScanner, and is believed to be clean.
>>
>>
>>
>
>
>--
>This message has been scanned for viruses and dangerous content by
>MailScanner, and is believed to be clean.
>


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.