5 ms·

> smalltalk cutest feature is the named parameter syntax trick (I don't like tricks but let's make an exception). And yet, Smalltalk got it wrong by making all

> smalltalk cutest feature is the named parameter syntax trick (I don't like tricks but let's make an exception). And yet, Smalltalk got it wrong by making all the parameter names mandatory, which leads to sources that are much more verbose than they need to be. The correct approach to this is to make parameter names optional, so they're only used when disambiguation is necessary to clarify the intent of the code.

igouy 9y ago
> by making all the parameter names mandatory For example?
- rahoulb 9y ago
  In smalltalk the parameter names aren't mandatory in the sense of many other languages. They are actually part of the method name. So robot put: thing in: container. And robot put: thing on: shelf. Are two separate messages that are both understood by the robot instance - "put: in:" vs "put: on:"
  - igouy 9y ago
    I asked hota_mazi to provide an example which demonstrated what they were talking about, to explain why they said "Smalltalk got it wrong by making all the parameter names mandatory". Are you hota_mazi ?
- hota_mazi 9y ago
  In languages where parameter names are optional, you can say foo(1, 1, create = true) This is the best of both worlds, allowing you to only name parameters when there can be ambiguity (for example when the function takes two int parameters and both mean very different things). Smalltalk forces you to always name your parameters, which leads to overly verbose source files.
  - igouy 9y ago
    I don't think any of us know what: foo(1, 1, create = true) :is supposed to do. Please show a meaningful example so we can see whether the Smalltalk is overly verbose or your alternative is overly ambiguous.
    - hota_mazi 9y ago
      I tried to pick up an example as generic as possible so you could understand my general point instead of focusing on this specific example, and you choose to focus on this specific example. <sigh>. How about this: createWindowAtCoordinates(10, 10, redraw = true) vs createWindowAtCoordinates(x = 10, y = 10, redraw = true) Regardless of how you feel about this specific example, surely you can agree that it's not always necessary to specify all the parameter by names?
      - igouy 9y ago
        So you mean that in this case we might assume the conventional order x coordinate first and y coordinate second would be understood. However (the specifics always matter) if we're assuming that, and we're bothered about verbosity then why say: createWindowAtCoordinates(10, 10, redraw = true) :instead of assuming that it will be understand that the window will be created at a point: createWindowAt(10, 10, redraw = true) :and something more like a Smalltalk method send: Window new openAt: 10@10 redraw: true :where we've used the x then y convention, and a binary message @, to create a point (without mandatory parameter names).
        hota_mazi 9y ago
        > So you mean that in this case we might assume the conventional order x coordinate first and y coordinate second would be understood ... and again, you focus on the specific example and completely miss my more general point. I'll give this one more try: I prefer a language that gives me the option of specifying the parameters names over one that forces me to always specify them.

igouy 9y ago

> by making all the parameter names mandatory For example?

rahoulb 9y ago
In smalltalk the parameter names aren't mandatory in the sense of many other languages. They are actually part of the method name. So robot put: thing in: container. And robot put: thing on: shelf. Are two separate messages that are both understood by the robot instance - "put: in:" vs "put: on:"
- igouy 9y ago
  I asked hota_mazi to provide an example which demonstrated what they were talking about, to explain why they said "Smalltalk got it wrong by making all the parameter names mandatory". Are you hota_mazi ?
hota_mazi 9y ago
In languages where parameter names are optional, you can say foo(1, 1, create = true) This is the best of both worlds, allowing you to only name parameters when there can be ambiguity (for example when the function takes two int parameters and both mean very different things). Smalltalk forces you to always name your parameters, which leads to overly verbose source files.
- igouy 9y ago
  I don't think any of us know what: foo(1, 1, create = true) :is supposed to do. Please show a meaningful example so we can see whether the Smalltalk is overly verbose or your alternative is overly ambiguous.
  - hota_mazi 9y ago
    I tried to pick up an example as generic as possible so you could understand my general point instead of focusing on this specific example, and you choose to focus on this specific example. <sigh>. How about this: createWindowAtCoordinates(10, 10, redraw = true) vs createWindowAtCoordinates(x = 10, y = 10, redraw = true) Regardless of how you feel about this specific example, surely you can agree that it's not always necessary to specify all the parameter by names?
    - igouy 9y ago
      So you mean that in this case we might assume the conventional order x coordinate first and y coordinate second would be understood. However (the specifics always matter) if we're assuming that, and we're bothered about verbosity then why say: createWindowAtCoordinates(10, 10, redraw = true) :instead of assuming that it will be understand that the window will be created at a point: createWindowAt(10, 10, redraw = true) :and something more like a Smalltalk method send: Window new openAt: 10@10 redraw: true :where we've used the x then y convention, and a binary message @, to create a point (without mandatory parameter names).
      - hota_mazi 9y ago
        > So you mean that in this case we might assume the conventional order x coordinate first and y coordinate second would be understood ... and again, you focus on the specific example and completely miss my more general point. I'll give this one more try: I prefer a language that gives me the option of specifying the parameters names over one that forces me to always specify them.