What is wrong with
def some_method(ladidah); return ladidah; end
However, the views of the Ruby community developed in the way that using
;is deemed bad taste: it is a sign that you are cramming too much—several logical phrases—into one line
And I don’t think this argument makes any sense, because the new syntax in 3.0 does exactly the same. it just looks different, and in my opinion the above is easier and quicker to understand.
Matz has been very accommodating in allowing different styles of
programming to be available for Ruby users because he designed it
to create programmer’s happiness.
People can read the story of the inclusion of endless methods and
the ongoing discussion of its use and/or necessity. But it always comes
down to allowing programmer choice, because it’s certainly not necessary.
However, let me provide a specific case where I think it would make the
Crystal source code more concise, shorter, and argurably more readable.
In the Crystal sourece file:
there is this code.
def abs : self
self >= 0 ? self : -self
end
def round(mode : RoundingMode) : self
self
end
def ceil : self
self
end
def floor : self
self
end
def trunc : self
self
end
# Returns `self`.
def round_even : self
self
end
# Returns `self`.
def round_away
self
end
# :inherit:
#
# Always returns `true` for `Int`.
def integer? : Bool
true
end
As in some of the Ruby blog examples using endless methods, this
could easily be shortened, with no loss of understanding, as below.
def (abs : self) = self >= 0 ? self : -self
def (round(mode : RoundingMode) : self) = self
def (ceil : self) = self
def (floor : self) = self
def (trunc : self) = self
# Returns `self`.
def (round_even : self) = self
# Returns `self`.
def (round_away) = self
# :inherit:
#
# Always returns `true` for `Int`.
def (integer? : Bool) = true
Personally, I see it as a serious waste of space to use 3 loc (lines of code)
for each method to express these simple definitions. I find the later much
more visually appealing, but also cognitively more direct, with less coding noise.
But again, these are my personal preferences.
However, I think it’s an attractive feature of a language|community to be amenable to
diverse styles of programming, if it doesn’t come at great cost to implement and maintain.
You can indeed emulate parts of this syntax using macros and the []= operator: Carcin
It is so functionally similar to a read-only property (i.e. getter) that I don’t think there ever needs to be compiler support for it. This is syntactically impossible with a Ruby attr_reader, so they have to invent a new syntax for this. Crystal is already more powerful in this regard.
That’s a big if, and it doesn’t stop at that; it also includes third-party code editors, syntax highlighters etc. that are not necessarily written in Crystal itself. Already the Crystal playground doesn’t handle automatic indentation correctly when there is a trailing if. All these little things add up to affect people’s impression of the language, its tooling, and ecosystem, especially new users, and usually in the negative direction. So “programmer happiness” is not a simple measurement based solely on the developers who are already using that language for quite some time.
I’m not very interested in Endless methods. If the Crystal language is mature enough and there is a need to improve the details of the grammar, it’s okay to have it, but I don’t mind if it’s not there until then.
That’s very nice; easier than I thought it would take (though I don’t understand most of it yet).