[deleted]
Gem adds support for creating state machines for attributes on any Ruby class
21–30 of 50 posts
Re: Gem adds support for creating state machines for attributes on any Ruby class
#22[dead]
Re: Gem adds support for creating state machines for attributes on any Ruby class
#23I think Ruby is OK enough, but what is this? state_machine :state, initial: :parked do I think in their zeal to "golf" the language, they forgot to actually keep it readable
I've been writing Ruby for about 16 years, and I find that eminently readable. You're apply state_machine to the attribute state , and giving it an initial value of :parked . Then there's a block that ostensibly encapsulates state transitions following (hence the do ). Ruby can be written extremely tersely, and that can be difficult for non-Rubyists to read. This might help: state_machine(:state, {:initial => :parked…
[deleted]
Re: Gem adds support for creating state machines for attributes on any Ruby class
#24I think Ruby is OK enough, but what is this? state_machine :state, initial: :parked do I think in their zeal to "golf" the language, they forgot to actually keep it readable
everyone in this chain is forgetting to mention a core design principal of Ruby.
Matz wants a principal of least surprise. That doesn't mean _your_ least surprise as a non-Ruby programmer, or someone with passing familiarity with the language. It means the least surprise of someone who has worked with the language for years. What Matz has said is that C++ continues to surprise him years and years in, and he _didn't_ want that to be the case for Ruby.
Re: Gem adds support for creating state machines for attributes on any Ruby class
#25I think Ruby is OK enough, but what is this? state_machine :state, initial: :parked do I think in their zeal to "golf" the language, they forgot to actually keep it readable
I've been writing Ruby for about 16 years, and I find that eminently readable. You're apply state_machine to the attribute state , and giving it an initial value of :parked . Then there's a block that ostensibly encapsulates state transitions following (hence the do ). Ruby can be written extremely tersely, and that can be difficult for non-Rubyists to read. This might help: state_machine(:state, {:initial => :parked…
[deleted]
Re: Gem adds support for creating state machines for attributes on any Ruby class
#26Earlier quoted context omitted.
I've been writing Ruby for about 16 years, and I find that eminently readable. You're apply state_machine to the attribute state , and giving it an initial value of :parked . Then there's a block that ostensibly encapsulates state transitions following (hence the do ). Ruby can be written extremely tersely, and that can be difficult for non-Rubyists to read. This might help: state_machine(:state, {:initial => :parked…
Wait, is :state a keyword or an instance attribute? Using the same syntax for both seems really confusing.
Ruby doesn't have "instance attributes". Instance variables are prefixed with "@". Anything prefixed by ":" is a symbol.
In some contexts we use symbols to refer to methods by name.
Anything you might thing is an "attribute" is likely a method. E.g. on some_object.name, name is always a method. You might be confused because e.g. "attr_reader" takes symbol arguments, because it's just another method. E.g. "attr_reader :foo" defines a method named "foo" to return "@foo". ":foo" there is a Symbol representing the name "foo".
Re: Gem adds support for creating state machines for attributes on any Ruby class
#27Earlier quoted context omitted.
I've been writing Ruby for about 16 years, and I find that eminently readable. You're apply state_machine to the attribute state , and giving it an initial value of :parked . Then there's a block that ostensibly encapsulates state transitions following (hence the do ). Ruby can be written extremely tersely, and that can be difficult for non-Rubyists to read. This might help: state_machine(:state, {:initial => :parked…
Positionally-significant colons is more nightmarish than significant whitespace. Speaking as a critic of significant whitespace. Put them at the front and make them mean something, or put them at the back and make them mean something, Making both places mean something entirely different, or even allowing both as an allowable syntax, is horrible for readability.
They mean "symbol" either way, except when trailing ":" also means they're a key.
I'd be inclined to agree it's a wart, but not that it affects readability to any noticeable amount.
In this case, though, the DSL looks just awful to me.
Re: Gem adds support for creating state machines for attributes on any Ruby class
#28Re: Gem adds support for creating state machines for attributes on any Ruby class
#29I'm not sure why this is interesting enough to post. It's an old gem, and the DSL seems awfully verbose to me for how little it does. I love Ruby, but I wouldn't want to write Ruby like this...
Re: Gem adds support for creating state machines for attributes on any Ruby class
#30Earlier quoted context omitted.
I've been writing Ruby for about 16 years, and I find that eminently readable. You're apply state_machine to the attribute state , and giving it an initial value of :parked . Then there's a block that ostensibly encapsulates state transitions following (hence the do ). Ruby can be written extremely tersely, and that can be difficult for non-Rubyists to read. This might help: state_machine(:state, {:initial => :parked…
I find it way easier to read this modified version — and I use ruby at work. It’s not even close.
I think the choice to "name" all arguments (`from:`, `to:`, which if I recall from my bygone Ruby days is implicitly parsed as a single hash argument) goes a long way to make things more consistent compared to having the first argument passed separately, making the colons a lot harder to parse visually due to the inconsistency.