Alternatives to JavaBean accessors conventions / Question mark & bang conventions?

[flbulgarelli]

A convention present on the Ruby and Elixir languages for messages is to append a question mark to those which return boolean values, and a bang for those which have effect.

I find this conventions quite helpful when teaching, since they allow you to easier reveal the intention of the code. For example, lets some selectors based on the token clear

• clear!: it clears the state of the object - for example collection.clear!
• clear?: it tells whether the idea is clear - for example lesson.clear?
• clear: it tells the value of the clear property - for example button.css.clear

It is less verbose the the JavaBeans convention - it seems wollok is following that convention currently:

• clear / or sometimes doClear: it clears the state of the object
• isClear: it tells whether the idea is clear
• getClear: it tells the value of the clear property

Could we introduce this convention in the wollok lang?

[PalumboN]

Like!

[flbulgarelli]

I am generalizing this question even more: why are we using JavaBean conventions for accessors?

I understand that accessor discussion is a long standing open discussion, but in the meanwhile we are starting naming methods using that get/set/is convention, and I think it is not an organic decision, but inertia.

Examples:

• position.getAllElements()
• exception.getMessage()
• etc

JavaBeans convention - get/set/is prefixes - is known to be quite verbose, in particular in the case of the get: it is absolutely redundant to add it, it adds not expressiveness to the method:

Examples:

• position.allElements()
• exception.message()
• etc

The is/set prefixes are more subtle. I think that something like 4.between?(4, 5) is as expressive as 4.isBetween(4, 5), perhaps a little more, but I agree like it is not so different and may be a matter of taste.

[flbulgarelli]

@faloi @fedescarpa @npasserini @javierfernandes @mfreyre @asanzo @gastonprieto

[npasserini]

I like it, in my courses I do not use pepita.getEnergia() but pepita.energia()

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

@faloi https://github.com/faloi @fedescarpa https://github.com/fedescarpa @npasserini https://github.com/npasserini @javierfernandes https://github.com/javierfernandes

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

[matifreyre]

I like the idea of avoiding get/set. I don't use those, like Nico... I like the Smalltalk convention more.

I do like the is* convention though, it makes it more like a question. I'm not a fan of having special characters as part of the selectors, but I won't be offended if we decide to use them.

[asanzo]

Ok, I'd like to give some structure to my answer, hope I'm brief.

• First: taste. My taste is smalltalkian. "Me gusta la cerveza fría, la tele fuerte y mis getter no verbosos". I like to reveal side effect by using imperative method names, and reveal return type by using conventions like starting/ending with a noun, an is and using plural (for example isAlive returns boolean and cheapFruits returns a collection of fruits). And I don't want to differentiate getters from other methods because this breaks encapsulation. BUT my taste is the least important thing, when deciding about Wollok. I can't emphazise this enough.
• Second: regarding industry's conventions, best practices, and usefull skills. If you learn intention revealing tricks using just the method name, you can use it afterwards in every language. I find this important, and something to take into account.
• Third: The most important thing in my opinion regarding this matter is the original purpose of Ozono, which I think should remain in Wollok: Is it good for learning?. Or paraphrasing, Can we make the decision thinking about the pedagogical and didactical advantages?

About the third aspect (pedagogical) I feel I need more information. As soon as I read this paper: http://dl.acm.org/citation.cfm?id=2534973 I will give a better anwer. If we choose a special syntax , I'd like to choose it having in mind these questions: are side-effect methods vs question methods a big problem among our students? Are return types problems more common or less common compared to these? Can we have special syntax for each of these problems (for example, if something returns a collection end it with an asterisk (*))? ¿Will a type-inferent IDE change these answers?

I'll keep thinking :)

[flbulgarelli]

If we choose a special syntax , I'd like to choose it having in mind these questions: ¿are side-effect methods vs question methods a big problem among our students? ¿Are return types problems more common or less common compared to these? ¿Can we have special syntax for each of these problems (for example, if something returns a collection end it with an asterisk (*))?

Nice questions. I don't have a definitive answer to them, just tastes and biased thoughts. We should actually conduct experiments here.

¿Will a type-inferent IDE change these answers?

I would like to add another question, though: IDE is good and we want it, sure. But how dependent will us be of it? And what will we do on final exams that are paper based?

Perhaps the answer is as obvious and crude: we should not have paper-based programming exams any more. After the few days of experimentation in a Mumuki-based course, I am starting to get convinced that it is actually possible

[npasserini]

If the objective of wollok is to be widely used (which I think it is) we should keep the doors open. So, while I think that it is a good idea to have Mumuki-based exams, we have to think also for people for which this is not a possibility.

Either way, I do not think that type inference has a big impact in the examination process, since the type information is used to catch mistakes while you are learning, while you do not know. At the exam type inference could help but it should not be crucial.

Stil, I am not sure how type inference could change my naming conventions, I tend to think it would not.

On Fri, Feb 5, 2016 at 12:59 PM, Franco Leonardo Bulgarelli < notifications@github.com> wrote:

If we choose a special syntax , I'd like to choose it having in mind these questions: ¿are side-effect methods vs question methods a big problem among our students? ¿Are return types problems more common or less common compared to these? ¿Can we have special syntax for each of these problems (for example, if something returns a collection end it with an asterisk (*))?

Nice questions. I don't have a definitive answer to them, just tastes and biased thoughts. We should actually conduct experiments here.

¿Will a type-inferent IDE change these answers?

I would like to add another question, though: IDE is good and we want it, sure. But how dependent will us be of it? And what will we do on final exams that are paper based?

Perhaps the answer is as obvious and crude: we should not have paper-based programming exams any more. After the few days of experimentation in a Mumuki-based course, I am starting to get convinced that it is actually possible

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

[flbulgarelli]

Finally we decided to use Smalltalk-style accessors:

peptia.energia(40);
pepita.energia();

@fdodino @npasserini @matifreyre @mmatos

This will apply for new methods from now on.

Old methods should be renamed iteratively.