On the first point, empty parentheses, the general idea regarding syntax is: (A) encourage a clear and simple style, and (B) don’t bother programmers with pesky syntax issues.
Compare with optionality of semicolons: (A) the recommend style is to omit semicolons between lines (instructions, declarations) because they bring absolutely nothing and instead obscure reading, and include a semicolon between instructions/declarations on the same line for similarly obvious reasons of readability; (B) ignore extra semicolons, and don’t require semicolons, because this is a small matter and it does not cause any semantic risk (wrong program behavior). (In rare cases the semicolon has to be included to remove potential ambiguity.)
With empty parentheses: (A) They obscure the text and bring no semantic value. (B) Who in the world would write empty parentheses?
The answer to the last question is: only someone who has done too much C, C++, Java etc. and is keeping the only style he knows. We are sympathetic of course (that’s one of the reasons we benignly look the other way when they add unnecessary semicolons all over the place.) But then (A) comes back because if such a person is encouraged to continue in that style he will naturally write things like an_account.balance () and then, the day balance changes from a function to an attribute, he will be stuck. In other words he loses the advantage of Eiffel’s Uniform Access principle. Small short-time syntactic convenience (preserve a classical if sloppy idiom) traded for big long-term semantic problem.
-- BM
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.
I am trying to look at the case of () as the one who used to program in the world where () are mandatory for function calls and they are unlikely to get the subtle difference between optionality of ; (semicolon) and (). So, the syntax rule for () is more stricter than for ; - it implies that programmers are forced to do things they were so used to in a different manner and they are unlikely to see much value initially that one can redefine a function with no arguments into constant or variable attribute (though it is a very elegant solution which I used a lot). So, for me it is mostly phycological aspect rather than technical .... Compiler may give just style recommendation but not the syntax error message ...
Moreover, all the viewers (short form, flat form, source code restored from internal representation) will follow the Eiffel style guidelines ignoring the mess one may have in his/her source code
So, probably I should have asked if it makes sense to make treatment of () a bit more relaxed …
Kind regards, Alexey
a.do_something; a.do_something_else; a.do_another thing
b.do_something; b.do_something_else; b.do_another thing
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.
Dear Philippe,
> multiple lines on the same line separated by semicolons is a "code smell".
Here our tastes differ. I prefer this
if x > y then -- Swap
t := x ; x := y ; y := t
end
to the version using two more lines. Clarity does not mean length. For straightforward elements concision is good. Lengthiness should be reserved for more elaborate stuff. At least that’s my approach.
I am influenced in part by my experience of writing programs for publications, where the number of lines matter. In that case using a whole line for every short instruction implies removing a line of text somewhere and is not worth it.
But even in a program meant just for compilation and execution rather than publication I don’t see anything wrong in packing a couple of short instructions into a line. Again a matter of taste, but I would not legislate in this area.
Thanks for the comments,
-- BM
From: eiffel...@googlegroups.com [mailto:eiffel...@googlegroups.com] On Behalf Of Larry Rix
Sent: Friday, February 8, 2019 17:15
To: Eiffel Users <eiffel...@googlegroups.com>
--
Woland's Cat <wolan...@gmail.com>:
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.
Indeed. But if we wanted to lift that restriction I think we could. Does not seem like a big deal to implement. The question is whether it’s worth it or we fear it would lead to a baroque explosion of multiple names for the same thing. As to me in the absence of clear counter-arguments I would go for it. Give programmers that flexibility.
It goes well with Unicode.
-- BM
--