Re: Proposal: Default Parameters/Named Parameters

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Rick Byers [MSFT] (rbyers_at_online.microsoft.com)
Date: 02/08/05

  • Next message: John Puopolo: "Determining .NET Install Directories" 
    Date: Tue, 08 Feb 2005 20:06:26 GMT

    Of course, you're right - the requirement to re ngen an image when any of
    its referenced assemblies changes means the burned-in defaults would be
    updated. I don't know what I was thinking - thanks for keeping me honest
    <grin>. Note, by the way, that in his whiteboard talk Anders indicated that
    the burn-in problem may not be that important.

    Having the compiler emit a series of overloads also sounds like a decent
    option (although it does still increase the complexity and potential for
    error in overload resolution). However, during his whiteboard talk,
    Anders' mentioned the possibility of object initialization syntax that may
    be an even better option. Basically, instead of writing default arguments
    like this:

    public MyClass( int arg1=0, string arg2="foo", object arg3=null )

    you would use properties like this:

    public MyClass()
    {
        Arg1=0;
       Arg2="foo";
       Arg3=null;
    }
    public int Arg1 { get {...} set {...} }
    public string Arg2 { get { ... } set {...} }
    public object Arg3 { get {...} set {...} }

    And then you could easy create an instance with a statement like
    new MyClass{ Arg1=4, Arg3=o }

    If you didn't want to expose your constructor parameters as properties
    (i.e. you didn't want to let people change them after construction), you
    could just wrap them all up in a struct and use the object construction
    syntax to create a set of values that you pass to the constructor. This
    would also be usefull for other (non-constructor) methods with long
    argument lists.

    I like this a lot (especially since it's avoids the overload resolution
    complexity in languages like C++, and doesn't require any CLR support).
    There is something about optionally named arguments I've always found
    appealing, and Anders' suggestion has that same appeal. Hopefully we'll
    see something like this in C# 3. Of course, I have no idea how likely this
    would be. If you like it, you should vote on it in the product feedback
    center
    (http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=
    6efe5713-405f-4808-9449-9caa0f116d6f).

    Rick

    --------
    This posting is provided "AS IS" with no warranties, and confers no rights.
    --------------------
    > From: "cody" <deutronium@gmx.de>
    > Subject: Re: Proposal: Default Parameters/Named Parameters
    > Date: Tue, 8 Feb 2005 00:42:52 +0100
    >
    > > Note that emitting default values at JIT time wouldn't cover the
    important
    > > case where the caller is an ngen'd image. It's not clear to me off hand
    > > how you could support that scenario in an efficient manor.
    >
    > Maybe I understood you wrong. In case of an NGened image we simple pass
    > *all* of the parameters to the method in the order they are declared in
    it.
    > At the end there is no performance penalty because when programming with
    the
    > main method pattern to fake optional parameters using heavy overloading
    we
    > also have to call the main method with *all* parameters.
    >
    > What would happen if I change the default value? In that case the method
    > signature has changed in which case the NGened images are incompatible
    and
    > have to be recompiled anyway.
    >
    > Another great idea is that we use the same syntax I proposed, but we let
    the
    > c# compiler emit the various overloaded methods so they do not clutter
    our
    > sourcecode anymore but instead are located in the assembly. This way we
    stay
    > very compatible because we do not have to modify the CLR but only the c#
    > compiler and we dealt gracefully with modifying default values because
    they
    > are stored in the assembly.
    > But this approach has its drawbacks - we can only omit the parameters
    from
    > the end of the parameter list and cannot simply leave some arguments out.
    > But I think this would be very enough for the most common uses.
    >
    > > I'd personally love to see something like this, but only if it could be
    > > efficiently implemented without sacrificing the simplicity and elegance
    of
    > > C#. The complexity of overload resolution in C++ (and resulting costs)
    > > was
    > > probably a driving factor in the C# design. I know Anders and his team
    > > have spent some effort trying to come up with an acceptable solution
    here
    > > (and they would have asked for CLR support if they thought it would
    help).
    > >
    > > Regardless, feel free to add your comments and vote to this topic in the
    > > MSDN product feedback center:
    > >
    http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=8
    > > 2bdeff1-0588-4c9d-9172-7c4f1eab0f8c
    > >
    > > We take that feedback very seriously, and try to allocate our resources
    in
    > > proportion to the demand from the community.
    > >
    > > Rick
    > >
    > > --------
    > > This posting is provided "AS IS" with no warranties, and confers no
    > > rights.
    > > --------------------
    > >> From: "Bruce Wood" <brucewood@canada.com>
    > >> Newsgroups:
    > >
    microsoft.public.dotnet.framework.clr,microsoft.public.dotnet.languages.csha
    > > rp
    > >> Subject: Re: Proposal: Default Parameters/Named Parameters
    > >> Date: 2 Feb 2005 11:22:29 -0800
    > >>
    > >> Anders Hejlsberg touched on this during his (very interesting)
    > >> whiteboard talk:
    > >>
    > >>
    > >
    http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20040624csharp
    > > ah/manifest.xml
    > >>
    > >> Basically, there are several ways to implement default arguments.
    > >>
    > >> The first is to have the compiler build the defaults into the method
    > >> call on the caller's side. Essentially the called method would receive
    > >> all of its parameter arguments every time and not have to worry about
    > >> missing arguments, because the caller would take care of filling in the
    > >> blank. Hejlsberg's objection to this is that it would involve compiling
    > >> the defaults into the caller, which would break all of your callers if
    > >> you ever changed the defaults.
    > >>
    > >> However, you're suggesting doing it during the JIT phase, which would
    > >> remove that objection, but require changes to the IL. An interesting
    > >> idea.
    > >>
    > >> The other possibility is to have the called method handle defaulting,
    > >> but this would come with a mondo speed penalty, as I think Hejlsberg
    > >> points out.
    > >>
    > >> Personally, the only place I've found that really could use optional
    > >> parameters is when writing constructors. Most other methods don't
    > >> experience the kind of massive overloading that constructors do, and
    > >> the only part of writing constructor overloads that I hate is having to
    > >> copy (and maintain) the documentation on every overload.
    > >>
    > >> Someone also mentions this to Hejlsberg as a compromise: allowing
    > >> sharing of XML documentation between overloaded methods / constructors.
    > >> That would make me happy enough, without changing the IL, the JITter,
    > >> and the definition of what a C# method signature looks like.
    > >>
    > >>
    > >
    >
    >
    >

  • Next message: John Puopolo: "Determining .NET Install Directories"

    Relevant Pages

    • Re: how do you overload methods...
      ... I believe that the constructor of the TreeViewCollection has been set to ... The error message is a bit misleading though (it suggests that there is a ... public constructor that does not have zero args - and hence in that case you ... > different return type does not constitute an overload. ...
      (microsoft.public.dotnet.languages.csharp)
    • Accessing controls on another form.
      ... >>> End Sub ... > Now the problem is I have used the overload in normal funtions and subs ... Dave, overloading a constructor is done the exact same way, although I'm ... Store the Form1 reference for later use. ...
      (microsoft.public.dotnet.languages.vb)
    • Re: Accessing controls on another form.
      ... >> Now the problem is I have used the overload in normal funtions and subs ... > Dave, overloading a constructor is done the exact same way, although I'm ... Store the Form1 reference for later use. ... > private Form1 myParent; ...
      (microsoft.public.dotnet.languages.vb)
    • Re: beginner c++ homework questions... if anyone knows how to do this, any help would be greatly app
      ... >4) Write a default constructor for the Money Class that initializes ... Money Class that initialises a Money object to $0.00. ... For Q5 you need to "overload" the constructor. ... understand "overload" look it up or ask your instructor to explain. ...
      (comp.lang.cpp)