Please explain to this ruby noob if you have time, why use =? Why not some other less used symbol or symbol pair instead? What are they trying to achieve with this?
This entire syntax was unnecessary, undesired, and is flat-out a mistake. I’ve felt this way about most of the syntax changes since 2.0, with the exception of named parameters.
def initialize(text)
@text = text
end
def inspect
"#<#{self.class} #{text}>"
end
def ==(other)
other.is_a?(Word) && text == other.text
end
def initialize(text) = @text = text
def inspect = "#<#{self.class} #{text}>"
def ==(other) = other.is_a?(Word) && text == other.text
You can also do it like
define_method(:inspect) { |text| "#<#{self.class} #{text}>" }
def initialize(text)
= (@text = text)
def inspect
= ("#<#{self.class} #{text}>")
def ==(other)
= (other.is_a?(Word) && text == other.text)
edit: this is similar to our standard when writing one-liner methods in C#. A bit noisier because of types and visibility, but still pretty concise, imho.
public void Initialize(string text)
=> Text = text;
// I actually hate the above a bit because "=>"
// originally implied functional/no-side-effects
// in C#, but the world moves on.
public string Inspect()
=> $"{this.GetType().Name} {text}>";
public static bool operator== (Word a, Word b)
=> a.Text == b.Text;https://google.github.io/styleguide/jsguide.html#formatting-...
> Terminology Note: Horizontal alignment is the practice of adding a variable number of additional spaces in your code with the goal of making certain tokens appear directly below certain other tokens on previous lines.
>
> This practice is permitted, but it is generally discouraged by Google Style. It is not even required to maintain horizontal alignment in places where it was already used.
>
> Here is an example without alignment, followed by one with alignment. Both are allowed, but the latter is discouraged:
{
tiny: 42, // this is great
longer: 435, // this too
};
{
tiny: 42, // permitted, but future edits
longer: 435, // may leave it unaligned
};
The "compact" line format is something that is very information dense and really really hard to parse for a human's eye, compared to the clearly visually structured prior format.
Personally, if I'd see something like that outside of a code golf tournament, I'd run because that kind of code density means that at least one of the developer(s) believes themselves to be some kind of code wizard who loves Matrix-style display, and it means that new developers have a very steep learning curve ahead of them.
I do this commonly in the Perl I write. If I'm using a complex set of maps and greps to reorganize a structure, doing that inline can be useful to the developer because it can match mental state, but the later reader may be somewhat lost when seeing it depending on how much of the data state they've internalized. A nice comment to explain the intent is useful, and when you're already saving space by eliding syntax, keep a good ratio of action to code on the screen (which is really what we're optimizing for here most times anyway, right?)
Ask any typesetter. Blank space used well gives text breathing room, making it easier to parse visually.
In the former example, it is extremely easy to pick out what each method name is and a decent idea of what it does at a glance. In the latter, I have to read to even see the method names.
What is a typesetter? Someone or something which takes tree-structured sentences, cranks them into a linear sequence of words, which is arbitrarily chopped into a rectangular form, with the goal being that the rectangle appear evenly gray from a distance. Sometimes ugly hyphens are inserted into the middle of tokens.
I'd recommend your team to stop code-golfing... Even better: with this new syntax you MUST reduce the soft limit to around 50 lines per class, right?
And even if an extra line of separation is used, it's still 6 lines instead of 11.
The first snippet is much easier to read, and using this technique to get around your 100 line rules seems to be missing the point of the rule - or purposely subverting it.
1> (defstruct (word text) ()
text
(:method print (me stream pretty-p) (put-string `#<@(typeof me) @{me.text}>` stream))
(:method equal (me) me.text))
#<struct-type word>
2> (new (word "abc"))
#<word abc>
3> (equal *2 "abc")
t
I usually define print methods for complex structures with many slots, that are not expected to be externalized. Particularly if they are linked in a graph structure, where (even if you have the circular printing turned on to handle the cycles) the prints get large. You know, you wanted to just print the banana, but it was pointing to a gorilla, and basically a dump of the whole jungle ensued.
Nobody forces you to use them. I for one is extremely happy with most of the changes in recent years.
“Nobody forces you to use it” can justify just about any insane addition to a programming language. Nobody forces you to use any of C++’s zillion and one features, but because they exist you have to contend with their consequences even if you try to limit yourself to modern conventions.
We didn’t need two ways to define methods, one of which parses insanely in order to save a few keystrokes. Adding this didn’t make the language better, it made it more complicated for virtually zero net gain.
We have several more ways to define methods already, and always have. If you think this gives us two perhaps the problem is you don't know the language very well.
Choices like this, to create options to adjust how the code reads has always been central to the design of Ruby. It's an odd thing to be annoyed with Ruby over.
"Parses insanely" is highly subjective. It parses exactly as you should expect it to if familiar with Ruby. Some of it is not ideal, and will likely be addressed with adjustments to the grammar. In the meantime the simple fix is to add parentheses whenever in doubt.
Resorting to semantic-lawyering doesn’t add to your argument, it detracts from it. You know the point I was making.
If you’re thinking functional, everything looks like a function. Examples (pseudocode that may be valid Ruby)
x = 3
def x = 3
def x()
return 3
end
So why would you use different syntax for them?
There’s only one reason: impure functions. For these 3:
x = rand()
def x = rand()
def x()
return rand()
end
That, I expect, is why Ruby still has def.
In scala, there’s similar thinking, which also let to them using () not only for specifying function arguments, but also for indexing into arrays or dictionaries. After all, an immutable array
x = [10,20,30]
def x(i)
switch i
case 0 return 10
case 1 return 20
case 2 return 39
otherwise throw indexOutOfBounds
end
Another one is that you may want to expose the pesky detail that indexing into an array typically is a lot faster than calling a function to the programmers, so that they can get a decent idea about the performance of code they read. That can only work if you keep your execution model simple, though, and if your programmers can reasonably predict what the compiler does, and how that will run on the cpu. That worked fine for C in the 1970s, but not so well anymore today. I think Golang is an attempt to get back there.
int AddOne(int x) => x + 1;
or
void SetXToZero() => x = 0;
// type annotations are optional, if the compiler can infer them
def foo = 42
def bar(x: Int): String = {
// stuff
}
def bar(x: Int): String =
// stuff
end bar // end is optional def [functionname] = [body]
From what I'm seeing, though, they should've made parentheses mandatory around [body] until they could fix the parser problem. They could easily make them optional in some hypothetical future where they've corrected the issue.
That said, it seems like C# wins at solving this problem, where the `=>` syntax is used for both lambdas and one-liner functions.