Hey all, I really don''t want to start a flame war or get everyone all riled up, but I was slightly dismayed to see the recent introduction/re-introduction of a state machine into core. http://blog.envylabs.com/2009/08/the-rails-state-machine/ I was hoping to see things move towards being more lightweight. This seems pretty heavily coupled to ActiveRecord. A state machine is great and useful, but is it the beginning of a slippery slope? With it becoming part of core, I can see arguments for incorporating acts_as_tree, acts_as_taggable, and other types of "above and beyond core orm" type functions into core. My concern too is for the core team, here. There''s enough work to be done - to add more of these types of features into core means more maintenance and test overhead for you guys. Just my .02 - what is everyone else thinking? -- ========================Dan Pickett Principal Enlight Solutions, Inc http://EnlightSolutions.com http://www.twitter.com/dpickett --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Thu, Aug 6, 2009 at 5:19 PM, Dan Pickett<dan.pickett@gmail.com> wrote:> I really don''t want to start a flame war or get everyone all riled up, but I > was slightly dismayed to see the recent introduction/re-introduction of a > state machine into core. > > http://blog.envylabs.com/2009/08/the-rails-state-machine/ > > I was hoping to see things move towards being more lightweight. This seems > pretty heavily coupled to ActiveRecord.It''s a mixin from Active Model. What heavy coupling do you identify?> A state machine is great and useful, but is it the beginning of a slippery > slope? With it becoming part of core, I can see arguments for incorporating > acts_as_tree, acts_as_taggable, and other types of "above and beyond core > orm" type functions into core.The reasoning is that is such a common, widespread modeling concern that it makes sense to promote it to the core Active Model toolkit. These other acts_as_* you mention really are AR-specific and are less widely used. Their implementation reaches down to the database level. Whereas managing state, events, and transitions is entirely behavioral and model-agnostic. You could mix this in to any Ruby objects you like.> My concern too is for the core team, here. There''s enough work to be done - > to add more of these types of features into core means more maintenance and > test overhead for you guys.Heartily agreed. Best, jeremy
I agree with Jeremy. It''s a mixin and I imagine could come in handy for Rails internals at some point. Great addition and I''m looking forward to using it. On Aug 6, 9:09 pm, Jeremy Kemper <jer...@bitsweat.net> wrote:> On Thu, Aug 6, 2009 at 5:19 PM, Dan Pickett<dan.pick...@gmail.com> wrote: > > I really don''t want to start a flame war or get everyone all riled up, but I > > was slightly dismayed to see the recent introduction/re-introduction of a > > state machine into core. > > >http://blog.envylabs.com/2009/08/the-rails-state-machine/ > > > I was hoping to see things move towards being more lightweight. This seems > > pretty heavily coupled to ActiveRecord. > > It''s a mixin from Active Model. What heavy coupling do you identify? > > > A state machine is great and useful, but is it the beginning of a slippery > > slope? With it becoming part of core, I can see arguments for incorporating > > acts_as_tree, acts_as_taggable, and other types of "above and beyond core > > orm" type functions into core. > > The reasoning is that is such a common, widespread modeling concern > that it makes sense to promote it to the core Active Model toolkit. > > These other acts_as_* you mention really are AR-specific and are less > widely used. Their implementation reaches down to the database level. > Whereas managing state, events, and transitions is entirely behavioral > and model-agnostic. You could mix this in to any Ruby objects you > like. > > > My concern too is for the core team, here. There''s enough work to be done - > > to add more of these types of features into core means more maintenance and > > test overhead for you guys. > > Heartily agreed. > > Best, > jeremy
On Sat, Aug 8, 2009 at 21:15, Dan Croak <dcroak@thoughtbot.com> wrote:> > I agree with Jeremy. It''s a mixin and I imagine could come in handy > for Rails internals at some point. > > Great addition and I''m looking forward to using it.Definitely core material. Signup process? State machine. Shopping, checkout and payment? State machine. Same could apply for authorizing something over OAuth, booking procedures (and filling out other complex forms), invitation-based system and more. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---