Why default parameter values where not included in Java

Discussion in 'Java' started by axer, Feb 4, 2005.

  1. axer

    axer Guest

    I'm looking for any links or documentation that describes why default
    parameter values where not included in Java.

    I'm not looking for opinion on the matter, or for speculation.

    I'm only interested in information that DIRECTLY describes the issue,
    and listed in a reputable site or book.

    Thank you
    axer, Feb 4, 2005
    #1
    1. Advertising

  2. axer

    Rhino Guest

    "axer" <> wrote in message
    news:...
    > I'm looking for any links or documentation that describes why default
    > parameter values where not included in Java.
    >
    > I'm not looking for opinion on the matter, or for speculation.
    >
    > I'm only interested in information that DIRECTLY describes the issue,
    > and listed in a reputable site or book.
    >

    I've been coding Java for several years and I don't know what you're talking
    about.

    What default parameters are you looking for? Java and the JVMs seem to have
    lots of defaults in them; for example, if you don't specify a memory
    parameter, a default amount of memory is assumed.

    I'm not sure what you're hoping to find either; it's not that often that a
    company will write documentation about why they DIDN'T do something.
    Documentation usually covers things that were done, not omitted.

    I suppose you *might* find something like interviews with top designers at
    Sun explaining why they took a certain path and chose not to take some other
    path that could touch on whatever you're after. Sun has some chat
    transcripts at java.sun.com so if you look through those you might find what
    you want.

    But without knowing more clearly what you want, I can't suggest more than
    that.

    Rhino
    Rhino, Feb 4, 2005
    #2
    1. Advertising

  3. axer

    Adam Maass Guest

    "Rhino" <> wrote:
    >
    > "axer" <> wrote:
    >> I'm looking for any links or documentation that describes why default
    >> parameter values where not included in Java.
    >>
    >> I'm not looking for opinion on the matter, or for speculation.
    >>
    >> I'm only interested in information that DIRECTLY describes the issue,
    >> and listed in a reputable site or book.
    >>

    > I've been coding Java for several years and I don't know what you're
    > talking
    > about.
    >
    > What default parameters are you looking for? Java and the JVMs seem to
    > have
    > lots of defaults in them; for example, if you don't specify a memory
    > parameter, a default amount of memory is assumed.
    >


    I believe the OP means the C++ feature that looks like this:

    void myMethod(int aParameter = 3) {
    // do something useful with aParameter
    }

    Now, you can call myMethod with:

    myMethod()


    and the parameter 'aParameter' gets set to the value '3'.


    But you can also call myMethod with:

    myMethod(7)

    and the parameter 'aParameter' is set to the value '7'.



    I know the OP asked us not to speculate, but this one is so blindingly easy
    that it's obvious.

    In Java, you simply write overloaded methods:

    void myMethod() {
    myMethod(3);
    }

    void myMethod(int aParameter) {
    // do something useful with aParameter
    }


    It cuts down on the amount of syntax, and Java was meant to be a simpler
    language than C++.


    By the way, you could also write the overloaded methods in C++, but there
    are subtle differences between default parameters and overloaded methods --
    that I don't quite grok, as I've never been a particularly proficient C++
    programmer.

    -- Adam Maass
    Adam Maass, Feb 4, 2005
    #3
  4. axer

    axer Guest

    ** Please, no debates, or speculations. We'll just waste your time and
    my time. **

    This is exactly why I asked for no speculation, because every Java
    programmer I've asked this question always gives me incorrect logic.
    As I'm sure you're aware of, your method is called overloading.
    And the overloading method takes much more syntax then does using
    default parameters. See example below:

    I'm not interested in debating this issue, or speculation, because I
    don't expect most Java programmers to fully understand the advantages
    of default parameter arguments, nor how easy it is to implement into a
    language.

    That's why I'm only interested in any links or references to reputable
    sites or book(s) that will DIRECTLY state the Java designers reason for
    not including default parameter arguments in Java.

    ** Please, no debates, or speculations. We'll just waste your time and
    my time. **


    //The C/C++ way using defautl parameters
    int ShowMessage(string MainMsg, string Title = "Info", int MessageType
    = FooWarning, int MessageButtons = IDOK)
    {
    //Do message
    }

    The above is much easier to understand, easier to maintain, and easier
    to find what you're looking for then the following Java overloaded
    method:

    int ShowMessage(string MainMsg, string Title, int MessageType, int
    MessageButtons)
    {
    //Do message
    }

    int ShowMessage(string MainMsg, string Title, int MessageType)
    {
    return ShowMessage(MainMsg, Title, MessageType, IDOK);
    }

    int ShowMessage(string MainMsg, string Title)
    {
    return ShowMessage(MainMsg, Title, FooWarning, IDOK);
    }

    int ShowMessage(string MainMsg)
    {
    return ShowMessage(MainMsg, "Info", FooWarning, IDOK);
    }
    axer, Feb 4, 2005
    #4
  5. wrote in comp.lang.java.programmer:
    > ** Please, no debates, or speculations. We'll just waste your time and
    > my time. **


    Sorry, but Usenet does not work like that.

    You throw us a question and we discuss it. If our discussion
    answers your question or is helpful in some other way, that
    is just a coincidence.

    > This is exactly why I asked for no speculation, because every Java
    > programmer I've asked this question always gives me incorrect logic.
    > As I'm sure you're aware of, your method is called overloading.


    So, how exactly do you spot the incorrect logic? Is it because
    you already know the answer and are just trolling the group?
    Is it because you have formed an opinion and the explanations
    don't fit it? Maybe you should think about not being such an
    harc core language fanatic?

    > I'm not interested in debating this issue, or speculation, because I
    > don't expect most Java programmers to fully understand the advantages
    > of default parameter arguments, nor how easy it is to implement into a
    > language.


    Yeah, you're just trolling. And you're not even good at it.

    --
    Antti S. Brax Rullalautailu pitää lapset poissa ladulta
    http://www.iki.fi/asb/ http://www.cs.helsinki.fi/u/abrax/hlb/
    "Disconnect this cable to shorten, re-connect to lengthen."
    -- Instructions on Logitech's USB mouse extension cord.
    Antti S. Brax, Feb 4, 2005
    #5
  6. Adam Maass wrote:
    > I believe the OP means the C++ feature that looks like this:
    >
    > void myMethod(int aParameter = 3) {
    > // do something useful with aParameter
    > }


    axer wrote:
    > ** Please, no debates, or speculations. We'll just waste your time
    > and my time. **


    You do realise you are the one wasting other peoples time
    by not making it clear what you are asking about.

    Adam Maass made a guess.

    You did not even bother quoting him and saying if that is what you mean.

    Instead you harp on about how you think Usenet ought to work.

    > That's why I'm only interested in any links or references to reputable
    > sites or book(s) that will DIRECTLY state the Java designers reason
    > for not including default parameter arguments in Java.


    The Java designers did not consider the C++ style method default
    argument feature worthwhile.

    A better question would be
    why did Stroustrup consider it worthwhile putting into C++?

    Others have pondered over the severely limited virtues
    of method default parameters features
    <http://c2.com/cgi/wiki?EmulateKeywordAndDefaultParameters>


    > ** Please, no debates, or speculations. We'll just waste your time
    > and my time. **


    You may opt to request of others what you would like them to do.
    Others may opt to honour your request if they feel like it.
    Thomas Schodt, Feb 4, 2005
    #6
  7. axer

    Adam Maass Guest

    "axer" <> wrote:
    >
    >
    > //The C/C++ way using defautl parameters
    > int ShowMessage(string MainMsg, string Title = "Info", int MessageType
    > = FooWarning, int MessageButtons = IDOK)
    > {
    > //Do message
    > }
    >
    > The above is much easier to understand, easier to maintain, and easier
    > to find what you're looking for then the following Java overloaded
    > method:
    >
    > int ShowMessage(string MainMsg, string Title, int MessageType, int
    > MessageButtons)
    > {
    > //Do message
    > }
    >
    > int ShowMessage(string MainMsg, string Title, int MessageType)
    > {
    > return ShowMessage(MainMsg, Title, MessageType, IDOK);
    > }
    >
    > int ShowMessage(string MainMsg, string Title)
    > {
    > return ShowMessage(MainMsg, Title, FooWarning, IDOK);
    > }
    >
    > int ShowMessage(string MainMsg)
    > {
    > return ShowMessage(MainMsg, "Info", FooWarning, IDOK);
    > }
    >


    I don't disagree with you. And the client of the class in question would
    have the same interface using either approach.

    My reference to "less syntax" does not equate to "less verbose" or even
    "more clear." I think the default parameter syntax was left out of Java
    because -- from the perspective of a client of the class -- the same effect
    can be achieved with method overloading, and method overloading was going to
    be incorporated into Java anyway for other reasons, and the syntax for
    default parameters in C++ just complicates the parsing rules of the language
    for very little perceived benefit. Again, let me emphasize: from the
    perspective of a client of the class, not an author or maintainer of the
    class.

    In addition, the way default parameters are implemented in (most flavors of)
    C++ would be difficult to achieve in Java given its dynamic class loading
    scheme. So even if default parameters had been carried over into Java from
    C++, it is likely that the language spec would have required Java compilers
    to treat any default parameter syntax as a shorthand for method overloading.

    -- Adam Maass
    Adam Maass, Feb 4, 2005
    #7
  8. axer

    axer Guest

    >>I don't disagree with you. And the client of the class in question
    would
    >>have the same interface using either approach.
    >>My reference to "less syntax" does not equate to "less verbose" or

    even
    >>"more clear." I think the default parameter syntax was left out of

    Java
    >>because -- from the perspective of a client of the class -- the same

    effect
    >>can be achieved with method overloading, and method overloading was

    going to
    >>be incorporated into Java anyway for other reasons, and the syntax

    for
    >>default parameters in C++ just complicates the parsing rules of the

    language
    >>for very little perceived benefit. Again, let me emphasize: from the
    >>perspective of a client of the class, not an author or maintainer of

    the
    >>class.


    You're the first Java developer to come up with a reason that sounds
    remotely possible and/or logical.


    >>In addition, the way default parameters are implemented in (most

    flavors of)
    >>C++ would be difficult to achieve in Java given its dynamic class

    loading
    >>scheme. So even if default parameters had been carried over into Java

    from
    >>C++, it is likely that the language spec would have required Java

    compilers
    >>to treat any default parameter syntax as a shorthand for method

    overloading.

    What would be wrong with the Java compiler converting it to overloaded
    methods?
    I don't see what problems this would cause.
    For example
    http://java.sun.com/j2se/1.3/docs/api/javax/swing/JOptionPane.html
    In the above link, if you look at the showMessageDialog method,
    you'll see there are four overloaded methods.
    Some or all of these methods could have been combined into one method
    with default values.

    If the compiler converted the following function into four separate
    methods, how would that cause a problem?

    int ShowMessage(string MainMsg, string Title = "Info", int MessageType
    = FooWarning, int MessageButtons = IDOK);

    Since it seems that no one really knows the official reason for this
    feature not being included in the language, I guess I'll venture down
    the debate road.
    To be perfectly honest, my opinion is firm as to whether default
    arguments are good for a language in GENERAL.

    What I'm not sure of is whether default arguments are good for Java
    specifically.

    So what is unique about Java that would make it incompatible with
    default parameter values, compare to other languages like C/C++?
    axer, Feb 4, 2005
    #8
  9. axer

    Guest

    On 2005-02-04, axer <> wrote:
    >>>I don't disagree with you. And the client of the class in question would
    >>>have the same interface using either approach.


    >>>My reference to "less syntax" does not equate to "less verbose" or even
    >>>"more clear." I think the default parameter syntax was left out of Java
    >>>because -- from the perspective of a client of the class -- the same effect
    >>>can be achieved with method overloading, and method overloading was going
    >>>to be incorporated into Java anyway for other reasons, and the syntax for
    >>>default parameters in C++ just complicates the parsing rules of the
    >>>language for very little perceived benefit. Again, let me emphasize: from
    >>>the perspective of a client of the class, not an author or maintainer of
    >>>the class.


    > You're the first Java developer to come up with a reason that sounds
    > remotely possible and/or logical.


    You are a goob.

    > Since it seems that no one really knows the official reason for this
    > feature not being included in the language, I guess I'll venture down
    > the debate road.


    How dare you waste my time! Do this! Do that!

    --
    Alan Gutierrez -
    , Feb 4, 2005
    #9
  10. axer

    Chris Uppal Guest

    axer wrote:

    > That's why I'm only interested in any links or references to reputable
    > sites or book(s) that will DIRECTLY state the Java designers reason for
    > not including default parameter arguments in Java.


    There are a number of people hereabouts who are certainly as "reputable"
    sources of information and insight as whatever sites or book(s) you are likely
    to find. But your tone is not such as to encourage them to respond helpfully.

    FWIW, I believe that default arguments are simply incompatible with Java
    semantics. Its a matter of the differences between the name resolution schemes
    in C++ and Java, but I'll leave you to look up the details yourself.

    -- chris
    Chris Uppal, Feb 4, 2005
    #10
  11. axer

    axer Guest

    >>There are a number of people hereabouts who are certainly as
    "reputable"
    I'm certain there are. But I can not use them as a reference.

    >>I believe that default arguments are simply incompatible with Java
    >>semantics. Its a matter of the differences between the name

    resolution
    >>schemes in C++ and Java, but I'll leave you to look up the details

    yourself.

    Specifically what name resolution differences?
    axer, Feb 4, 2005
    #11
  12. axer

    Roland Guest

    On 4-2-2005 16:00, Adam Maass wrote:

    > "axer" <> wrote:
    >
    >>
    >>//The C/C++ way using defautl parameters
    >>int ShowMessage(string MainMsg, string Title = "Info", int MessageType
    >>= FooWarning, int MessageButtons = IDOK)
    >>{
    >> //Do message
    >>}
    >>
    >>The above is much easier to understand, easier to maintain, and easier
    >>to find what you're looking for then the following Java overloaded
    >>method:
    >>
    >>int ShowMessage(string MainMsg, string Title, int MessageType, int
    >>MessageButtons)
    >>{
    >> //Do message
    >>}
    >>
    >>int ShowMessage(string MainMsg, string Title, int MessageType)
    >>{
    >> return ShowMessage(MainMsg, Title, MessageType, IDOK);
    >>}
    >>
    >>int ShowMessage(string MainMsg, string Title)
    >>{
    >> return ShowMessage(MainMsg, Title, FooWarning, IDOK);
    >>}
    >>
    >>int ShowMessage(string MainMsg)
    >>{
    >> return ShowMessage(MainMsg, "Info", FooWarning, IDOK);
    >>}
    >>

    >
    >
    > I don't disagree with you. And the client of the class in question would
    > have the same interface using either approach.
    >
    > My reference to "less syntax" does not equate to "less verbose" or even
    > "more clear." I think the default parameter syntax was left out of Java
    > because -- from the perspective of a client of the class -- the same effect
    > can be achieved with method overloading, and method overloading was going to
    > be incorporated into Java anyway for other reasons, and the syntax for
    > default parameters in C++ just complicates the parsing rules of the language
    > for very little perceived benefit. Again, let me emphasize: from the
    > perspective of a client of the class, not an author or maintainer of the
    > class.
    >
    > In addition, the way default parameters are implemented in (most flavors of)
    > C++ would be difficult to achieve in Java given its dynamic class loading
    > scheme. So even if default parameters had been carried over into Java from
    > C++, it is likely that the language spec would have required Java compilers
    > to treat any default parameter syntax as a shorthand for method overloading.
    >
    > -- Adam Maass
    >
    >

    Adam, your reasoning matches strikingly well with the Java design goals
    written down by James Gosling and Henry McGilton in the "The Java
    Language Environment" whitepaper (1996).

    A quote from Chapter 2 "Java -- Simple and Familiar", section 2
    [emphasis added]:
    <quote>
    The first step was to eliminate redundancy from C and C++. In many ways,
    the C language evolved into a collection of overlapping features,
    providing too *many ways to say the same thing*, while in many cases not
    providing needed features. C++, in an attempt to add "classes in C",
    merely added more redundancy while retaining many of the inherent
    problems of C.
    </quote>

    I could not find any direct reference to default parameter values in the
    whitepaper. IOW and as I interpret it: default parameter values have
    been not been included in Java, because it can be equally expressed by
    other means (method overloading).

    The whitepaper can be found at Sun's Java site:
    <http://java.sun.com/docs/white/langenv/>.

    It's fun to read why the didn't include enums (section 2.2.3). While
    other sections have a title starting with "No *more* ...", section 2.2.3
    is called "No Enums". Somehow I get the feeling they already consider
    enums for a future version (and now, as we all know, enums have made it
    in Java 5).
    --
    Regards,

    Roland de Ruiter
    ___ ___
    /__/ w_/ /__/
    / \ /_/ / \
    Roland, Feb 4, 2005
    #12
  13. axer

    axer Guest

    > "axer" <> wrote:

    >>//The C/C++ way using defautl parameters
    >>int ShowMessage(string MainMsg, string Title = "Info", int

    MessageType
    >>= FooWarning, int MessageButtons = IDOK)
    >>{
    >> //Do message
    >>}



    >>The above is much easier to understand, easier to maintain, and

    easier
    >>to find what you're looking for then the following Java overloaded
    >>method:



    >>int ShowMessage(string MainMsg, string Title, int MessageType, int
    >>MessageButtons)
    >>{
    >> //Do message
    >>}



    >>int ShowMessage(string MainMsg, string Title, int MessageType)
    >>{
    >> return ShowMessage(MainMsg, Title, MessageType, IDOK);
    >>}



    >>int ShowMessage(string MainMsg, string Title)
    >>{
    >> return ShowMessage(MainMsg, Title, FooWarning, IDOK);
    >>}



    >>int ShowMessage(string MainMsg)
    >>{
    >> return ShowMessage(MainMsg, "Info", FooWarning, IDOK);
    >>}



    > I don't disagree with you. And the client of the class in question

    would
    > have the same interface using either approach.



    > My reference to "less syntax" does not equate to "less verbose" or

    even
    > "more clear." I think the default parameter syntax was left out of

    Java
    > because -- from the perspective of a client of the class -- the same

    effect
    > can be achieved with method overloading, and method overloading was

    going to
    > be incorporated into Java anyway for other reasons, and the syntax

    for
    > default parameters in C++ just complicates the parsing rules of the

    language
    > for very little perceived benefit. Again, let me emphasize: from the
    > perspective of a client of the class, not an author or maintainer of

    the
    > class.



    > In addition, the way default parameters are implemented in (most

    flavors of)
    > C++ would be difficult to achieve in Java given its dynamic class

    loading
    > scheme. So even if default parameters had been carried over into Java

    from
    > C++, it is likely that the language spec would have required Java

    compilers
    > to treat any default parameter syntax as a shorthand for method

    overloading.

    >>Adam, your reasoning matches strikingly well with the Java design

    goals
    >>written down by James Gosling and Henry McGilton in the "The Java
    >>Language Environment" whitepaper (1996).
    >>A quote from Chapter 2 "Java -- Simple and Familiar", section 2
    >>[emphasis added]:
    >><quote>
    >>The first step was to eliminate redundancy from C and C++. In many

    ways,
    >>the C language evolved into a collection of overlapping features,
    >>providing too *many ways to say the same thing*, while in many cases

    not
    >>providing needed features. C++, in an attempt to add "classes in C",
    >>merely added more redundancy while retaining many of the inherent
    >>problems of C.
    >></quote>
    >>I could not find any direct reference to default parameter values in

    the
    >>whitepaper. IOW and as I interpret it: default parameter values have
    >>been not been included in Java, because it can be equally expressed

    by
    >>other means (method overloading).


    The same could be said for enums. As the link you posted shows:
    http://java.sun.com/docs/white/langenv/Simple.doc2.html#5627

    By the way, thanks for the link. I've been looking for a good list
    showing the difference between C++ and Java, and your link seems to
    cover it pretty good.
    axer, Feb 4, 2005
    #13
  14. axer

    Roland Guest

    On 4-2-2005 20:43, axer wrote:
    >>>Adam, your reasoning matches strikingly well with the Java design

    >
    > goals
    >
    >>>written down by James Gosling and Henry McGilton in the "The Java
    >>>Language Environment" whitepaper (1996).
    >>>A quote from Chapter 2 "Java -- Simple and Familiar", section 2
    >>>[emphasis added]:
    >>><quote>
    >>>The first step was to eliminate redundancy from C and C++. In many

    >
    > ways,
    >
    >>>the C language evolved into a collection of overlapping features,
    >>>providing too *many ways to say the same thing*, while in many cases

    >
    > not
    >
    >>>providing needed features. C++, in an attempt to add "classes in C",
    >>>merely added more redundancy while retaining many of the inherent
    >>>problems of C.
    >>></quote>
    >>>I could not find any direct reference to default parameter values in

    >
    > the
    >
    >>>whitepaper. IOW and as I interpret it: default parameter values have
    >>>been not been included in Java, because it can be equally expressed

    >
    > by
    >
    >>>other means (method overloading).

    >
    >
    > The same could be said for enums. As the link you posted shows:
    > http://java.sun.com/docs/white/langenv/Simple.doc2.html#5627
    >

    I'm not sure what it is you are wanting to say here. Gosling c.s. *did
    not* add enums to the Java language, *because* (at the time) they
    thought it could equally be expressed other means, i.e. "by declaring a
    class whose only raison d'etre is to hold constants" [quoted from the
    link above].
    --
    Regards,

    Roland de Ruiter
    ___ ___
    /__/ w_/ /__/
    / \ /_/ / \
    Roland, Feb 4, 2005
    #14
  15. axer

    Chris Smith Guest

    axer <> wrote:
    > If the compiler converted the following function into four separate
    > methods, how would that cause a problem?


    It wouldn't, by itself, cause a problem. Very few such features, in and
    of themselves, cause any problem. If you create a language with a bunch
    of them, though, then you get C++. Java was designed to *not* be
    something like C++ for a number of reasons:

    1. Sun believed that serious software could be developed using a
    language with a simpler and easier to understand language definition,
    and that the result could lead to higher quality of software.

    2. Sun wanted to encourage fast adoption of Java by a very large group
    of developers, and was not willing to bet on anyone spending the time
    needed to become familiar with another C++.

    3. Java needed to be safely portable across implementations of compilers
    and virtual machines, and adding more complexities to the language makes
    that harder to achieve, and to test that it has been achieved.

    4. Java achieved an aesthetic sense of being a small and simple
    language, and adding more features would interfere with that goal.

    The issue is not whether the feature could save a few lines of code.
    People who believe that an extra language feature is justified because
    it saves them five lines of code do *not* program in Java. The issue is
    also not whether the feature is easy to implement; obviously, it is.
    The issue is what effect the feature has on the central concepts and
    design of the Java programming language. Clearly, it is opposed to the
    concepts behind Java 1.0, and it's inclusion would have been
    discongruous at best.

    It is far less clear that default parameters would be at all out of
    place in Java 1.5, which has backed off of Java 1.0's direction to a
    large extent (e.g., variable argument lists, enums, autoboxing, static
    import, and so on); and it remains to be seen whether default parameters
    will eventually be added as well.

    > Since it seems that no one really knows the official reason for this
    > feature not being included in the language, I guess I'll venture down
    > the debate road.


    The problem is deeper than that no one knows. There is no "official"
    reason. Sun doesn't publish opinions a la U.S. Supreme Court justices.
    They make and release products, and the reasons of various team members
    may have different reasons for making the same decision. You could look
    for comments by James Gosling, who led the team and probably wrote much
    of the code, but that's still not an "official" reason.

    --
    www.designacourse.com
    The Easiest Way To Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
    Chris Smith, Feb 5, 2005
    #15
  16. axer

    Chris Smith Guest

    axer <> wrote:
    > You're the first Java developer to come up with a reason that sounds
    > remotely possible and/or logical.


    Whatever. I just wrote a long response before I saw this. Now I
    realize you're just trolling. Thanks for wasting my time.

    --
    www.designacourse.com
    The Easiest Way To Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
    Chris Smith, Feb 5, 2005
    #16
  17. "axer" <> writes:

    > The same could be said for enums. As the link you posted shows:
    > http://java.sun.com/docs/white/langenv/Simple.doc2.html#5627


    If you want an implementation of default parameters in Java, submit a
    request to the JCP. One possible implementation could be that the
    compiler generated the necessary overloaded methods, e.g. turned

    public void foo(String fie = "dummy") { }

    into the class-file versions of both

    public void foo(String fie) {
    }

    and

    public void foo() { foo("dummy); }

    The problem comes in the case of two neighbour arguments of the same
    type: Which of the two should a "reduced" argument list use? i.e.

    public void foo(int x = 0, int y = 42) { }

    should result in

    public void foo(int x) { foo(x, 42); }

    or

    public void foo(int y) { foo(0, y); }

    ? Your proposal need to cover that case, e.g. by stating a rule that
    the first argument will be "exposed" to the programmer.
    Tor Iver Wilhelmsen, Feb 5, 2005
    #17
  18. Tor Iver Wilhelmsen <> scribbled the following:
    > The problem comes in the case of two neighbour arguments of the same
    > type: Which of the two should a "reduced" argument list use? i.e.


    > public void foo(int x = 0, int y = 42) { }


    > should result in


    > public void foo(int x) { foo(x, 42); }


    > or


    > public void foo(int y) { foo(0, y); }


    > ? Your proposal need to cover that case, e.g. by stating a rule that
    > the first argument will be "exposed" to the programmer.


    AFAIK C++ uses the same rule.

    --
    /-- Joona Palaste () ------------- Finland --------\
    \-------------------------------------------------------- rules! --------/
    "Normal is what everyone else is, and you're not."
    - Dr. Tolian Soran
    Joona I Palaste, Feb 5, 2005
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    878
    Mark Rae
    Dec 21, 2006
  2. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,840
    Smokey Grindel
    Dec 2, 2006
  3. Stuart Redmann
    Replies:
    5
    Views:
    477
    Stuart Redmann
    Dec 14, 2007
  4. wylbur37
    Replies:
    2
    Views:
    114
    Lasse Reichstein Nielsen
    Jan 2, 2004
  5. wylbur37
    Replies:
    12
    Views:
    192
    Michael C.
    Jun 5, 2004
Loading...

Share This Page