The new constructor/method call syntax about eo

[nqafield]

I like the general idea and reasoning for your change (I find some of this stuff not as readable as I might like) but the fact that, in the new idea, if: is an object and then: is the name of an argument (even thought they look identical) is not at all obvious and so it seems confusing.

[yegor256]

@gukoff yeah, I agree with @pa9ey It does look more similar to the good old Java, but it's not OOP any more. We have to make if an object with 3 arguments. In your example we have if, then and else -- three objects.

Also, keep in mind that long methods is a bad idea in the first place. They will have to be short in order to be readable. It's like in Lisp -- long structures are not readable and developers avoid them.

[gukoff]

the fact that, in the new idea, if: is an object and then: is the name of an argument (even thought they look identical) is not at all obvious and so it seems confusing.

@pa9ey well, it's all about their order. The first one is a main thing being called, the others mean some additional information. Yes, it is pretty unusual and isn't obvious at first glance. But I got used to it very quickly, while writing this issue :)

We have to make if an object with 3 arguments

@yegor256 yup, and these arguments have to be objects.

In your example we have if, then and else -- three objects.

Hmm. What do you mean? if is some standard library object here, and then and else are just the names of its constructor parameters. The new constructor accepts three objects, but so does the old one in our current example from the README as well.

[gukoff]

Actually, I was talking primarily about constructors. A method call would look like this:

filesystem file: '/tmp/x.txt' mode: 'r'

Or, the more complex example:

filesystem
    file:
        stripped: '__new_name.txt__' by_symbol: '_'
    mode:
        if: 
            filesystem writable
        then: 'rw'
        else: 'r'

[MadridianFox]

I see three levels of syntax.
First, basic relations of objects - instantiating and invoking of methods. All that above will be translated to this level. It's technical level.
Second, user friendly expressions: control statements, operators, etc - all that forms logic of method.
Third, level of composition of objects. This we not only instantiate and invoke. This it has a sense, and will be comfortable to see names of arguments.

What we have - first level is as third level, but without optional elements.
Second level - sugar for more readable composition of low-level, senseless objects.

[astynax]

Hello! May I bring some SmallTalk here? Take a look:

expr ifTrue: [statements to evaluate if expr] ifFalse: [statements to evaluate if not expr]

In the SmallTalk "if statement" is just a method (message) of some boolean expression, and ifTrue/ifFalse is just a named arguments of method if.

A smalltalk'ish version of fibonacci example will look like this:

create fibonacci(1) as Number:
  Number n
  bytes asBytes():
    lessThan: @n, 2
      ifTrue: 1
      ifFalse:
        plus:
          @n
          fibonacci:
            minus: @n, 1

And this example is even closer to FP: it looks just like a Church encoding of booleans:

true = (x, y) -> x
false = (x, y) -> y
if = (expr, then, else) -> expr(then, else)

if(lessThan(1, 2), "less", "greater") --> "less"

The main benefit of if as a method is type safety - if will be available only for "boolean" objects.

[yegor256]

@gukoff take a look at our new syntax, I believe you will like it