Optional methods parenthesis?

[flbulgarelli]

• good: solves the properties discussion: simply you don't need them, at least from the aesthetical point of view
• good: compact code
• bad: it adds an optional element to the language. As I said, it goes against simplicity
  • but: the parenthesis were already optional when you had a closure as las argument. So we are actually generalizing and simplifying that rule: parenthesis are optional... always. So it is *good

I was against proposing this feature/change, but I changed my opinion after realizing the last item

[flbulgarelli]

This is related to #517 and automatic constructors described in #559

With all those changes change, we could write something like the following:

//getters, methods with effect samples

class Golondrina {
   var energia  = 100
   var posicion
   method comer! = energia += 40
   method volarHacia!(destino) {
     energia -= 10 * posicion.distanciaA(destino)
     posicion = destino
   }
}

var pepita = Golondrina.new(posicion = BuenosAires)

//or perhaps ...
//var pepita = Golondrina.new(posicion: BuenosAires)
//that way we don't mix the variable assignment operator with the initialization semantic

pepita.comer!
pepita.volarHacia! santaFe

// setters sample
pepita.energia 20
//or perhaps we could use a convention that resembles Smalltak
//pepita.energia: 20

We are still not reifying the concept of accessor/property, but I am not sure we actually need that extra model complexity. Anyway, it is another - related - discussion.

[matifreyre]

I don't like this very much. I don't even agree with the single closure parameter case, although I can see sense in it. I prefer to always have the parenthesis, as currently says in the language reference

Of course this can be changed, but as I said I agree with it and I'd prefer to keep it as it is.

On Fri, Jan 1, 2016 at 2:33 PM, Franco Leonardo Bulgarelli < notifications@github.com> wrote:

This is related to #517 https://github.com/uqbar-project/wollok/issues/517 and automatic constructors described in #559 https://github.com/uqbar-project/wollok/issues/559

With all those changes change, we could write something like the following:

//getters, methods with effect samples

class Golondrina { var energia = 100 var posicion method comer! = energia += 40 method volarHacia!(destino) { energia -= 10 * posicion.distanciaA(destino) posicion = destino } }

var pepita = Golondrina.new(posicion = BuenosAires)

//or perhaps ... //var pepita = Golondrina.new(posicion: BuenosAires) //that way we don't mix the variable assignment operator with the initialization semantic

pepita.comer! pepita.volarHacia! santaFe

// setters sample pepita.energia 20 //or perhaps we could use a convention that resembles Smalltak //pepita.energia: 20

We are still not reifying the concept of accessor/property, but I am not sure we actually need that extra model complexity. Anyway, it is another - related - discussion.

— Reply to this email directly or view it on GitHub https://github.com/uqbar-project/wollok/issues/564#issuecomment-168318498 .

[javierfernandes]

As an "already" programmer, I think it is nice to avoid parenthesis, but just for no-args methods

val e = pepita.energia()

would become

val e = pepita.energia

But I guess this should be another "configurable" feature of the language, because I'm pretty sure I don't want newcomers/students to confuse it. They must know that the only thing they can do with an object is sending a message to it.

Then for >= 1 parameters method

• I'm not sure we can implement it with xtext grammar, since it seems it could drive us to parser ambiguities
• If we get around ambiguities, then, my experience with Scala which has this feature is that, it starts as a good idea, but in practice is terrible. Many times when you make a mistake the compiler error is terrible, and you end up adding parenthesis back, to understand what is wrong, just to later try to remove them again one by one, until you reach successfull compilation.

So, to summarise: I propose (configurable) optional parenthesis for no-args methods.

[matifreyre]

My concern is about beginners, as you say. How do I convince them that pepita.energia is not a direct access to the variable when it looks soooo much like it? It wouldn't do. I can agree with optional parenthesis in both of those cases (no parameters or a single closure parameter) if the "default" value is deactivated.

On Mon, Jan 4, 2016 at 10:33 PM, javierfernandes notifications@github.com wrote:

As an "already" programmer, I think it is nice to avoid parenthesis, but just for no-args methods

val e = pepita.energia()

would become

val e = pepita.energia

But I guess this should be another "configurable" feature of the language, because I'm pretty sure I don't want newcomers/students to confuse it. They must know that the only thing they can do with an object is sending a message to it.

Then for >= 1 parameters method

• I'm not sure we can implement it with xtext grammar, since it seems it could drive us to parser ambiguities
• If we get around ambiguities, then, my experience with Scala which has this feature is that, it starts as a good idea, but in practice is terrible. Many times when you make a mistake the compiler error is terrible, and you end up adding parenthesis back, to understand what is wrong, just to later try to remove them again one by one, until you reach successfull compilation.

So, to summarise: I propose (configurable) optional parenthesis for no-args methods.

— Reply to this email directly or view it on GitHub https://github.com/uqbar-project/wollok/issues/564#issuecomment-168864179 .

[matifreyre]

Any updates on this?

[fdodino]

Agree with Mati & Javi

[flbulgarelli]

Finally we decided to drop this feature. Parenthesis will be always mandatory, even for closures.

@matifreyre @fdodino @npasserini