Rightward assignment with a hash rocket?
I've been using ruby for a decade and I don't get why this is necessary (or even good).
Ruby adds experimental support for Rightward assignments
11–20 of 39 posts
Re: Ruby adds experimental support for Rightward assignments
#12I’d rather have changes to type safety, performance, or even a compiled binary.
Or a merger between crystal and interpreted mode
Re: Ruby adds experimental support for Rightward assignments
#13Earlier quoted context omitted.
At the expense of increasing the complexity to read code.
How is the complexity increased?
As you read through code you can come across a huge switch and not know why until you look to the end. Now you’re reading bottom-up, which is just as unnatural as right-to-left for english speakers.
Not necessarily more complex, but not less complex either IMO. I often say complexity can’t be eliminated, only spread around differently; I think we’re seeing that here.
Re: Ruby adds experimental support for Rightward assignments
#14Does sort of make a hash in Ruby more confusing to the untrained eye (unless the hash rocket is totally dead, I haven't written Ruby since like the 2.3 days):
{ "age" => age, "name" => name }
I like the idea a lot. It'd probably allow for some nice functional looking code, but that's also the problem... it'd only look functional. And I think without VM/compiler/runtime support of functional programming it's pretty much a big waste of time.
I can use piece shit for a shoehorn; doesn't mean I should.
Re: Ruby adds experimental support for Rightward assignments
#15I get why you'd want it, but I'm not sure they should be reusing => for it, since that already means something in Ruby.
Re: Ruby adds experimental support for Rightward assignments
#16Could this be an initial step towards elixir-like chaining?
"foobar" => upcase() => x
Re: Ruby adds experimental support for Rightward assignments
#17Does sort of make a hash in Ruby more confusing to the untrained eye (unless the hash rocket is totally dead, I haven't written Ruby since like the 2.3 days): { "age" => age, "name" => name } I like the idea a lot. It'd probably allow for some nice functional looking code, but that's also the problem... it'd only look functional. And I think without VM/compiler/runtime support of functional programming it's pretty mu…
No, the hash rocket still exists. However, if you use symbols as keys, you can replace ":foo => bar" with "foo: bar". Many people, of course, use hashes with symbols as keys, but whenever you don't, you still need to use the hashrocket syntax.
Re: Ruby adds experimental support for Rightward assignments
#18To me this seems like a clear loss. The syntax is (as far as I can tell) strictly more verbose than the existing assignment syntax. Ruby is already plagued by a million-and-one ways to do everything, but at least in other cases simplicity (à la zen of Python) trades off for brevity.
+100
Re: Ruby adds experimental support for Rightward assignments
#19Earlier quoted context omitted.
At the expense of increasing the complexity to read code.
How is the complexity increased?
Because now there are 2 ways to do the same thing with little obvious benefit other than syntactic bikeshedding.
2 ways to do something is more complex than 1.
But it's more than just the syntax of the code. It now means new lint rules, new coding standards in projects (some will allow => assignment, some will encourage conformity to legacy code, and others will disallow it entirely). There will be new Rubocop rules and other editor configs to update for proper syntax highlighting.
Syntactic changes like this with little obvious benefit need to be looked at skeptically. Just because something can be done, doesn't mean it should be.
Re: Ruby adds experimental support for Rightward assignments
#20I get why you'd want it, but I'm not sure they should be reusing => for it, since that already means something in Ruby.
Yeah, I also start getting confused by reusing of the syntax. Now there's also a proposal to use { 1, 2, 3 } to represent sets - but {} is already used for blocks of code and for maps, so now that will be essentially a 3rd use case for curly braces.
On the other hand Ruby has already such a extensive syntax that it's hard to come up with something else that would not already be taken. -> represents lambda, >> is a valid method name, etc.