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.