Re: Default parameter values for methods

Hi Matan,  I think we are discussing 2 separate (but related) enhancements
here:

1. Default values for parameters - that you started with
2. Named parameters that I have "plugged in"

I would like to get #1 done ASAP and then have a detailed proposal for #2
separately if the WG sees a need.

Thanks
Srini

On Mon, Jun 15, 2009 at 2:39 PM, Matan Vax <matan@cadence.com> wrote:

>  Hey Srini,
>
>
>
> Thanks for this comment. I'm ashamed to admit I wasn't even aware that SV
> supports named parameter syntax inside function calls. This is more elegant
> IMO than the empty expression placeholder. It's especially important when
> there are many parameters, many of which have defaults (but I don't think
> this happens too often).
>
>
>
> One problem here is that in e (like in C++, Java, etc.) parameter names are
> not considered part of the method signature. In other words, when you
> override a method you must restate the number and types of the parameters,
> but you don't have to give them the same name as in the initial declaration.
> I guess we could restrict the named parameter reference to names given in
> the declaration. Having done that, we may choose to relax the requirement to
> designate defaults to all rightmost parameters.
>
>
>
> By the way, named parameters can be emulated with the following simple
> design pattern: declare a class that wraps all parameters of the method, and
> assign them their default values in construction (init() method). So an
> actual call may look like:
>
>
>
>    my_struct.foo(new with { .a = FALSE; .c = TRUE; }); // use default for
> parameter b
>
>
>
> Obviously this involves some memory allocation overhead, but in most cases
> it is negligible. You can even use a macro to make the syntax look more like
> SV...
>
>
>
> I'm not sure how important this is. What do you think?
>
>
>
> Matan.
>
>
>

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