Re: [Rails-core] Could we add a new list for engines developers?

2012-07-21 Thread Pedro Nascimento
Which makes me think about it: What could we do to better improve rails lists organization in a way that would benefit most out of it? While I agree that a Rails engine/plugin mailing list is useful, perhaps forking Rails-talk into specific categories, even if keeping a general rails-talk mailing

Re: [Rails-core] Could we add a new list for engines developers?

2012-07-21 Thread Weston Platter
+1 for the need for a Rails Engine specific list. There will be a windfall of questions about migrating to Engines because of the Rails 4 deprecation of plugins (according to this change loghttp://weblog.rubyonrails.org/2012/1/4/rails-3-2-0-rc2-has-been-released/ ). Since most questions will

Re: [Rails-core] Could we add a new list for engines developers?

2012-07-21 Thread Luís Ferreira
Yes, but engines kinda sucked before 3.1. Now a lot more people are using them. +1 for the list. On Jul 21, 2012, at 2:29 AM, Andrew Kaspick wrote: Here's a past one... http://www.mail-archive.com/engine-users@lists.rails-engines.org/ dead! On Fri, Jul 20, 2012 at 8:28 PM, Ryan Bigg

Re: [Rails-core] sti_object.becomes(Parent) unexpectedly mutating the receiver

2012-07-21 Thread Nicolás Sanguinetti
-1 for the merge. +1 for a doc fix where this is more explicit. I've always used x.becomes(Foo) for the side effect (mutating x) instead of for the return value. As I see it, the name _becomes_ clearly states that the receiver is affected. If it was #convert or #cast or something that would

[Rails-core] Could Ruby Structs be useful to ActiveRecord?

2012-07-21 Thread Maurizio De Santis
Hello, recently I ran into Ruby Structshttp://www.ruby-doc.org/core-1.9.3/Struct.html. Some examples: # Create a structure with a name in StructStruct.new(Customer, :name, :address)#= Struct::CustomerStruct::Customer.new(Dave, 123 Main) #= #struct Struct::Customer name=Dave,

Re: [Rails-core] Could Ruby Structs be useful to ActiveRecord?

2012-07-21 Thread Steve Klabnik
The DAO pattern is totally different than the ActiveRecord pattern, so you probably won't see anything like this happen inside of AR itself. Other ORMs may do something like this, though. If your model is just a struct, then it has no 'domain' methods... -- You received this message because you

Re: [Rails-core] sti_object.becomes(Parent) unexpectedly mutating the receiver

2012-07-21 Thread Peter Brown
The reason I disagree with becomes mutating the object in place is because it's inconsistent with *almost* all of Ruby and Rails' APIs. Methods that mutate an object (or raise an exception) end with !. Whether it's a string, hash, or array, methods that mutate these objects have two versions.

Re: [Rails-core] sti_object.becomes(Parent) unexpectedly mutating the receiver

2012-07-21 Thread Steve Klabnik
Methods that mutate an object (or raise an exception) end with !. This isn't correct. dangerous methods end with !. It has nothing to do with mutation. -- 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

[Rails-core] Validation Hints

2012-07-21 Thread Ace Suares
The validations in rails (activemodel/activerecord) have the ability to produce errors that can be internationalized through I18n. I've been working on a gem called validation_hints, that provides hints on the attributes that have validations, that can be used as a tool tip or some other way

Re: [Rails-core] sti_object.becomes(Parent) unexpectedly mutating the receiver

2012-07-21 Thread Peter Brown
I apologize, I wasn't trying to turn this into a debate about semantics. Steve, does that mean you're in favor of updating the docs too then? If so, any interest in adding a version that doesn't have side effects? -- You received this message because you are subscribed to the Google Groups

Re: [Rails-core] sti_object.becomes(Parent) unexpectedly mutating the receiver

2012-07-21 Thread Steve Klabnik
I don't use this feature, so I don't have an opinion about the non-side effect version, but I don't see how changing the docs to make this behavior explicit would hurt anything. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to