Gem adds support for creating state machines for attributes on any Ruby class
1–10 of 50 posts
Re: Gem adds support for creating state machines for attributes on any Ruby class
#2I think Ruby is OK enough, but what is this?
state_machine :state, initial: :parked do
Re: Gem adds support for creating state machines for attributes on any Ruby class
#3I 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}) do
# transitions here
end
Re: Gem adds support for creating state machines for attributes on any Ruby class
#4I 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
It can come as "golf" language, but those features are used to achieve DSL capabilities
See how much mileage Lua gets by `f "a"` be `f("a")` or `f{a = 3}` be `f({a = 3})`. Haskell achieves the same
Re: Gem adds support for creating state machines for attributes on any Ruby class
#5I 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…
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.
Re: Gem adds support for creating state machines for attributes on any Ruby class
#6I 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…
Wait, is :state a keyword or an instance attribute? Using the same syntax for both seems really confusing.
Re: Gem adds support for creating state machines for attributes on any Ruby class
#7Earlier 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.
The colon sigil denotes a Symbol class literal, and a trailing colon here denotes a Symbol used as a Hash object key.
Re: Gem adds support for creating state machines for attributes on any Ruby class
#8I 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
This is idiomatic Ruby syntax, and anyone familiar with the language knows what that code does
Re: Gem adds support for creating state machines for attributes on any Ruby class
#9I 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 don't think this is bad, but my preference would be to change `initial` to `initially`. I'd probably also make :state the default name as well, but that may be too magical for some, especially those not used to Rail's omakase philosophy.
Re: Gem adds support for creating state machines for attributes on any Ruby class
#10I 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
Readability is one of Ruby's strengths. Most custom DSLs I've encountered are easy to understand. Arguably meta programing makes it harder but the language allows you to strike the balance that suits you.