RE: [sv-ec] Mantis 1857 - extern method types for parameterized classes

I agree with Mike's comments (and sympathize with Neil's ordering). I
believe that we could accept both forms (3) and (4), and consider from
(4) as a shorthand for (3). The shorthand form avoids in a somewhat
elegant way the problem of specifying the wrong (i.e., different)
default parameter type.

In particular, as Gord mentioned, form (3) - and (4) - are very
symmetric to the look of parameterized tasks and functions. The change I
propose is to allow form (4) for parameterized tasks/functions, and
since this form provides no default specialization, such tasks/functions
would *always* require an explicit specialization - something that I
consider a good methodology.

One final question, is the "type" keyword needed? 

	function #(T) T C::get();

    Arturo

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Neil
Korpusik
Sent: Wednesday, June 20, 2007 8:56 AM
To: Gordon Vreugdenhil
Cc: SV_EC List
Subject: Re: [sv-ec] Mantis 1857 - extern method types for parameterized
classes

Thanks to Gord and Mike for working on these alternatives.

Below are my preferences (the first one being the most desirable).
I actually prefer 4) or 3) a lot more than either 1) or 2). I
would even be willing to allow both 4) or 3) as being equivalent
alternatives. Users could choose the form (4 or 3)that most suites
their taste.


4) function #(type T) T C::get();
3) function #(type T = int) T C::get();
1) C::function T get();
2) function::C T get();

Neil



Gordon Vreugdenhil wrote On 06/20/07 07:17,:
> Mike Mintz and I exchanged a fair amount of email on the
> issue of dealing with return types for extern functions of
> parameterized classes.  We agree that, as in C++, one needs
> to be able to determine that names in the function return
> type can be recognized as such prior to parsing the return type.
> 
> We didn't agree on the style that should be used for such
declarations.
> 
> Here is the original simple example:
> 
>     class C #(type T = int);
>        T x;
>        extern function T get();
>     endclass
> 
> Here are some alternatives that we discussed for the external
definition:
>    1)  C::function T get();    // what I originally proposed
>    2)  function::C T get();
>    3)  function #(type T = int) T C::get();
> 
> 
> Some of the points in the discussion:
>    a) (3) is essentially what C++ does for template methods;
>       the template formals are duplicated and the combination
>       of that and the "C::get" gives you what you need.
>    b) (1) or (2) are just "short hands" for (3)
>    c) (2) could permit a full duplication of the template
>       parameters if we wanted:
>          function::C#(type T = int) T get();
>    d) (1) and (2) would allow but not require the class prefix
>       (C::) prior to "get".  (3) requires C::get.
>    e) If we adopt some variant of Mantis 696 (parameterized
>       tasks and functions) then (3) has a very symmetric
>       form with how parameterized functions would look, with
>       just the class prefix "C::" to indicate that is the
>       definition of an external (this is what C++ has as well).
> 
> The symmetry argument is very reasonable but I personally
> don't find it completely compelling.  I have a pretty
> strong bias against forced redundancies and the required
> cut-and-paste of the parameterization provides more
> opportunities for error with the symmetry being the only
> benefit.
> 
> I would be happier with a modified form (that Mike and I
> didn't discuss):
>     4) function #(type T) T C::get();
> since then at least you don't have to repeat defaults.
> 
> 
> Any of these solve the fundamental problem.  My preference
> is still (1) with (2), (4) and (3) being my choices in
> decreasing preference.
> 
> We should take this up in committee, but I would like to
> see if we can reach consensus on a preferred form via
> a straw poll of the group.  If there is a reasonable level
> of consensus on one form, I'd be happy to write that up
> prior to the next meeting.
> 
> Mike, I hope that I conveyed the core of the discussion
> in a fair manner.  If I mischaracterized anything, please
> jump in.  Thanks for the great discussion; your input
> is very valuable.
> 
> Gord.

-- 
---------------------------------------------------------------------
Neil Korpusik                                     Tel: 408-276-6385
Frontend Technologies (FTAP)                      Fax: 408-276-5092
Sun Microsystems                       email: neil.korpusik@sun.com
---------------------------------------------------------------------


-- 
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.