Hi, One of the things about the Rails code that people tend to frown upon is the Base class. I was wondering if anyone ever considered replacing it with with a class name that reflects the actual function of the class? Maybe we could even use ActiveRecord as a ''base class'' for models? Staying backwards compatible for a while – at least for application code – should be possible. http://gist.github.com/15813 Manfred --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Hi Manfred> One of the things about the Rails code that people tend to frown upon > is the Base class. I was wondering if anyone ever considered replacingCan you point me in the direction of some discussion of what''s wrong with the "Base class" that people "frown upon"? Just wondering, since I don''t recall a problem off-hand? --~--~---------~--~----~------------~-------~--~----~ 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 Oct 9, 2008, at 7:58 PM, S. Brent Faulkner wrote:> >> One of the things about the Rails code that people tend to frown upon >> is the Base class. I was wondering if anyone ever considered >> replacing > > Can you point me in the direction of some discussion of what''s wrong > with the "Base class" that people "frown upon"?I don''t know of any articles that talk about this, I''ve mostly discussed it face-to-face. And example of a project that changed their API is Datamapper, they went from: class Author < DataMapper::Base; end To class Author; include DataMapper::Resource; end> Just wondering, since I don''t recall a problem off-hand?There is no problem in the sense that tests are failing or a feature is broken. It''s just weird to have a class with a non-descriptive name. I get the feeling that the Base class was created because David wanted to create a namespace named ActiveRecord to prevent conflicts but also wanted to have something you could inherit from. ActiveRecord::ActiveRecord is weird, so it ended up being ActiveRecord::Base. I personally think ActiveRecord::Model or just ActiveRecord would have been a better name. I see a lot of people using this as an idiom in other Ruby libraries and applications because they learn their first Ruby by developing a Rails applications, even though this idiom might not fit their project. Manfred --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
It''s too major of a change to make imo and there''s just too many tutorials/docs out there that reference Class Model < ActiveRecord::Base. To me, it makes sense that a model "inherits from" ActiveRecord::Base because that''s where a model gets its methods from. ----- Ryan Bigg Freelancer http://frozenplague.net On 10/10/2008, at 9:01 AM, Manfred Stienstra wrote:> > > On Oct 9, 2008, at 7:58 PM, S. Brent Faulkner wrote: >> >>> One of the things about the Rails code that people tend to frown >>> upon >>> is the Base class. I was wondering if anyone ever considered >>> replacing >> >> Can you point me in the direction of some discussion of what''s wrong >> with the "Base class" that people "frown upon"? > > I don''t know of any articles that talk about this, I''ve mostly > discussed it face-to-face. > > And example of a project that changed their API is Datamapper, they > went from: > > class Author < DataMapper::Base; end > > To > > class Author; include DataMapper::Resource; end > >> Just wondering, since I don''t recall a problem off-hand? > > There is no problem in the sense that tests are failing or a feature > is broken. It''s just weird to have a class with a non-descriptive > name. > > I get the feeling that the Base class was created because David wanted > to create a namespace named ActiveRecord to prevent conflicts but also > wanted to have something you could inherit from. > ActiveRecord::ActiveRecord is weird, so it ended up being > ActiveRecord::Base. I personally think ActiveRecord::Model or just > ActiveRecord would have been a better name. > > I see a lot of people using this as an idiom in other Ruby libraries > and applications because they learn their first Ruby by developing a > Rails applications, even though this idiom might not fit their > project. > > Manfred > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
I always assumed that AR::Base and AC::Base''s name came from the concept of an abstract base class. I think ::Base is a fine name for the top-most superclass in a module, but that might just be a side effect of previous experience. -Trek On Thu, Oct 9, 2008 at 12:42 PM, Manfred Stienstra <manfred@gmail.com>wrote:> > Hi, > > One of the things about the Rails code that people tend to frown upon > is the Base class. I was wondering if anyone ever considered replacing > it with with a class name that reflects the actual function of the > class? Maybe we could even use ActiveRecord as a ''base class'' for > models? Staying backwards compatible for a while – at least for > application code – should be possible. > > http://gist.github.com/15813 > > Manfred > > > > >--~--~---------~--~----~------------~-------~--~----~ 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, Oct 9, 2008 at 3:56 PM, Ryan Bigg <radarlistener@gmail.com> wrote:> > It''s too major of a change to make imo and there''s just too many > tutorials/docs out there that reference Class Model < > ActiveRecord::Base. To me, it makes sense that a model "inherits from" > ActiveRecord::Base because that''s where a model gets its methods from.If you renamed ActiveRecord::Base to ActiveRecord::Model, then a model that inherited from ActiveRecord::Model would get its methods from ActiveRecord::Model. You could make this completely backwards compatible too. Just rename ActiveRecord::Base to ActiveRecord::Model and then: ActiveRecord::Base = ActiveRecord::Model That being said, I''d say that changing to a more accurate name isn''t worth the risk of confusion. Jeremy --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Regarding tutorials/docs -- would there really be a problem with doing this, then: class ActiveRecord Base = self end In other words, ::Base would still work, it''d just be redundant, and probably depricated. As for the clarity, there''s plenty of indirection anyway. I''d rather have a clear API. In fact, that is the whole point of Rails, to me -- having everything be clear, simple, and easy, so I have less to think about. ::Base is information I don''t need, and don''t care about. It''s not DRY, and it''s pointless. But I''m also not sure how much it''s worth arguing about. On Thu, Oct 9, 2008 at 5:56 PM, Ryan Bigg <radarlistener@gmail.com> wrote:> > It''s too major of a change to make imo and there''s just too many > tutorials/docs out there that reference Class Model < > ActiveRecord::Base. To me, it makes sense that a model "inherits from" > ActiveRecord::Base because that''s where a model gets its methods from. > > ----- > Ryan Bigg > Freelancer > http://frozenplague.net > > > > > > > > On 10/10/2008, at 9:01 AM, Manfred Stienstra wrote: > > > > > > > On Oct 9, 2008, at 7:58 PM, S. Brent Faulkner wrote: > >> > >>> One of the things about the Rails code that people tend to frown > >>> upon > >>> is the Base class. I was wondering if anyone ever considered > >>> replacing > >> > >> Can you point me in the direction of some discussion of what''s wrong > >> with the "Base class" that people "frown upon"? > > > > I don''t know of any articles that talk about this, I''ve mostly > > discussed it face-to-face. > > > > And example of a project that changed their API is Datamapper, they > > went from: > > > > class Author < DataMapper::Base; end > > > > To > > > > class Author; include DataMapper::Resource; end > > > >> Just wondering, since I don''t recall a problem off-hand? > > > > There is no problem in the sense that tests are failing or a feature > > is broken. It''s just weird to have a class with a non-descriptive > > name. > > > > I get the feeling that the Base class was created because David wanted > > to create a namespace named ActiveRecord to prevent conflicts but also > > wanted to have something you could inherit from. > > ActiveRecord::ActiveRecord is weird, so it ended up being > > ActiveRecord::Base. I personally think ActiveRecord::Model or just > > ActiveRecord would have been a better name. > > > > I see a lot of people using this as an idiom in other Ruby libraries > > and applications because they learn their first Ruby by developing a > > Rails applications, even though this idiom might not fit their > > project. > > > > Manfred > > > > > > > > > >--~--~---------~--~----~------------~-------~--~----~ 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, Oct 9, 2008 at 4:40 PM, David Masover <dave@3mix.com> wrote:> Regarding tutorials/docs -- would there really be a problem with doing this, > then: > > class ActiveRecord > Base = self > endThat breaks code that assumes ActiveRecord is a module and not a class, which is going to be a lot of code. Jeremy --~--~---------~--~----~------------~-------~--~----~ 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 10 okt 2008, at 01:43, Jeremy Evans wrote:> > On Thu, Oct 9, 2008 at 4:40 PM, David Masover <dave@3mix.com> wrote: >> Regarding tutorials/docs -- would there really be a problem with >> doing this, >> then: >> >> class ActiveRecord >> Base = self >> end > > That breaks code that assumes ActiveRecord is a module and not a > class, which is going to be a lot of code.That''s why such a change should only be introduced in a point release, which will break a lot of code anyway and this will probably be the easiest compatibility fix of all of them. So I don''t think that''s really an argument against it. I find Base the worst class name ever. It does not at all communicate it''s intention other than that it''s a base class for something. Eloy --~--~---------~--~----~------------~-------~--~----~ 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 Fri, Oct 10, 2008 at 10:58 AM, Eloy Duran <eloy.de.enige@gmail.com> wrote:> > On 10 okt 2008, at 01:43, Jeremy Evans wrote: > >> >> On Thu, Oct 9, 2008 at 4:40 PM, David Masover <dave@3mix.com> wrote: >>> Regarding tutorials/docs -- would there really be a problem with >>> doing this, >>> then: >>> >>> class ActiveRecord >>> Base = self >>> end >> >> That breaks code that assumes ActiveRecord is a module and not a >> class, which is going to be a lot of code. > > That''s why such a change should only be introduced in a point release, > which will break a lot of code anyway and this will probably be the > easiest > compatibility fix of all of them. So I don''t think that''s really an > argument against it. > > I find Base the worst class name ever. > It does not at all communicate it''s intention other > than that it''s a base class for something.It''s the base class for active record models. If you consider the name outside the context of the module it''s in, then yeah, it''s shit. But the same is true of almost every class that''s in a module, unless you do something weird like: Database::DatabaseConnection rather than Database::Connection Fundamentally though, the name is entrenched in every rails app out there, and we''d need a reason other than "ick" to go and change it, even in a 3.0 release.> Eloy > > > > >-- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
>>>> Regarding tutorials/docs -- would there really be a problem with >>>> doing this, >>>> then: >>>> >>>> class ActiveRecord >>>> Base = self >>>> end >>> >>> That breaks code that assumes ActiveRecord is a module and not a >>> class, which is going to be a lot of code. >> >> That''s why such a change should only be introduced in a point >> release, >> which will break a lot of code anyway and this will probably be the >> easiest >> compatibility fix of all of them. So I don''t think that''s really an >> argument against it. >> >> I find Base the worst class name ever. >> It does not at all communicate it''s intention other >> than that it''s a base class for something. > > It''s the base class for active record models. If you consider the > name outside the context of the module it''s in, then yeah, it''s shit. > But the same is true of almost every class that''s in a module, unless > you do something weird like: > > Database::DatabaseConnection > > rather than > > Database::ConnectionWell the only weird thing here is the same issue as with ActiveRecord::Base. In other words, name it: Product::DatabaseConnection.> Fundamentally though, the name is entrenched in every rails app out > there, and we''d need a reason other than "ick" to go and change it, > even in a 3.0 release.Actually in modern Rails apps, don''t know about older versions though, there is no occurrence at all of the string "module ActiveRecord". Anyways, I don''t think discussing these implementation details adds anything to a possible discussion about the original question. Because it is indeed, as you say, just an "ick" :) About the original question, I actually think Manfred really wanted to know if his assumption about why it was named this way by David was correct. [1] Any ideas on that? Cheers, Eloy [1]: "I get the feeling that the Base class was created because David wanted to create a namespace named ActiveRecord to prevent conflicts but also wanted to have something you could inherit from. ActiveRecord::ActiveRecord is weird, so it ended up being ActiveRecord::Base. I personally think ActiveRecord::Model or just ActiveRecord would have been a better name." -- Manfred --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
> About the original question, I actually think Manfred really wanted to > know > if his assumption about why it was named this way by David was > correct. [1] > Any ideas on that?I have no idea. But back in the dark ages when I did java programming, that was a common naming pattern. I expect that the bikesheds were traditionally painted another colour back then :).> Cheers, > Eloy > > [1]: "I get the feeling that the Base class was created because David > wanted > to create a namespace named ActiveRecord to prevent conflicts but also > wanted to have something you could inherit from. > ActiveRecord::ActiveRecord is weird, so it ended up being > ActiveRecord::Base. I personally think ActiveRecord::Model or just > ActiveRecord would have been a better name." -- Manfred > > > >-- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Can I just add that, since this is purely a bikeshed discussion, and there is TONS of code that inherits from ActiveRecord::Base (and others), there is no reason to repaint everyone''s bikeshed red just to satisfy the few people that have mentioned casually that they don''t really like blue? I suspect you''d hear quite the uproar breaking such a huge piece of compatibility. It is the way it is. On a related note, the "internals" change of Inflector -> ActiveSupport::Inflector and Dependencies -> ActiveSupport::Dependencies in Rails 2.1.1 actually broke alot of my code that was in Rakefiles and other places that was taking advantage of these very cool Rails modules. For this reason we''re stuck on Rails 2.1.0 until we can lockstep upgrade everything. It''s actually a huge pain in the butt, again for a needless bikeshed change. "Better" or "prettier" or "more proper" should never trump "incompatible". -Nate --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Then how would any software ever progress? I have Windows 95 software that''s incompatible with Windows XP. I still have licenses for OCX controls from VB4 that don''t work with .NET. But this incompatibility is necessary to ensure progress and refinement of the software products. I realize the change you mentioned is trivial and probably should have gone through a "holy crap this is going away phase", but I don''t think your point about it NEVER trumping incompatibility holds a lot of water. </thread_jack> --Jeremy On Mon, Oct 13, 2008 at 8:01 PM, Nate Wiger <nwiger@gmail.com> wrote:> > Can I just add that, since this is purely a bikeshed discussion, and > there is TONS of code that inherits from ActiveRecord::Base (and > others), there is no reason to repaint everyone''s bikeshed red just to > satisfy the few people that have mentioned casually that they don''t > really like blue? > > I suspect you''d hear quite the uproar breaking such a huge piece of > compatibility. It is the way it is. > > On a related note, the "internals" change of Inflector -> > ActiveSupport::Inflector and Dependencies -> > ActiveSupport::Dependencies in Rails 2.1.1 actually broke alot of my > code that was in Rakefiles and other places that was taking advantage > of these very cool Rails modules. For this reason we''re stuck on > Rails 2.1.0 until we can lockstep upgrade everything. It''s actually a > huge pain in the butt, again for a needless bikeshed change. > > "Better" or "prettier" or "more proper" should never trump > "incompatible". > > -Nate > > >-- http://jeremymcanally.com/ http://entp.com/ http://omgbloglol.com My books: http://manning.com/mcanally/ http://humblelittlerubybook.com/ (FREE!) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
It''s even more purely a bikeshed discussion than you mention, as there''s no particular reason this would break code that inherits from ActiveRecord::Base. Again: class ActiveRecord Base = self end Problem solved. If we want to purge ::Base, depricate it and remove it several versions later. The bigger problem is code which naively does this: module ActiveRecord ... end And I''ve found this to be a better practice anyway, especially with Rails autoloading: ActiveRecord.module_eval do ... end Which would work just fine, whether it''s a module or a class. In other words: This isn''t likely to break much code. It is very much a question of taste. No one''s suggesting that we rebuild the bikeshed, or change the locks -- only painting it a different color. On Mon, Oct 13, 2008 at 8:01 PM, Nate Wiger <nwiger@gmail.com> wrote:> > Can I just add that, since this is purely a bikeshed discussion, and > there is TONS of code that inherits from ActiveRecord::Base (and > others), there is no reason to repaint everyone''s bikeshed red just to > satisfy the few people that have mentioned casually that they don''t > really like blue? > > I suspect you''d hear quite the uproar breaking such a huge piece of > compatibility. It is the way it is. > > On a related note, the "internals" change of Inflector -> > ActiveSupport::Inflector and Dependencies -> > ActiveSupport::Dependencies in Rails 2.1.1 actually broke alot of my > code that was in Rakefiles and other places that was taking advantage > of these very cool Rails modules. For this reason we''re stuck on > Rails 2.1.0 until we can lockstep upgrade everything. It''s actually a > huge pain in the butt, again for a needless bikeshed change. > > "Better" or "prettier" or "more proper" should never trump > "incompatible". > > -Nate > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Going back to the origin of the thread, I''ve always thought there''s a missing ApplicationModel in Rails and in fact wrote a patch some time ago: http://dev.rubyonrails.org/ticket/10832 The only detail that I am doubting about is that Rails docs inherit from AR::Base in their example code and so Rails docs would change that to ApplicationModel. On the other hand AR can be used outside Rails where ApplicationModel would make no sense in general, and the docs are the same ones. Other than that, I''d personally like to have ApplicationModel someday. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
@Jeremy: You''re somewhat twisting my words, I''m not saying software should never change. Just that this is a purely cosmetic change. It doesn''t improve things. So there''s no real justification for it, other than "some people would prefer it a different way." There''s no reason to break things that ain''t broke. @David: Lots of plugins mixin to ActiveRecord::Base, or override methods. Are you going to volunteer to help all those maintainers fix them? And add nasty checks everywhere to see if Base is defined; else use the new "better" name? Now, Xavier mentions an interesting option that may satisfy both camps. Create an ApplicationModel like ApplicationController. There, a place for application-specific overrides (rather than environment.rb), and it doesn''t have that "Base" name that apparently bothers a few people. Rails is mature enough already, and depended upon enough already that renaming classes just for the sake of a "better name" should be completely out of the question. Giving an impression of instability is not something Rails needs. Just the opposite; Rails still needs to continue workingl at getting a reputation for being "rock solid" (to which great strides are being made with the new threading stuff, etc). -Nate --~--~---------~--~----~------------~-------~--~----~ 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 Tue, Oct 14, 2008 at 4:13 PM, Nate Wiger <nwiger@gmail.com> wrote:> > @Jeremy: You''re somewhat twisting my words, I''m not saying software > should never change. Just that this is a purely cosmetic change.Cosmetic changes are actually largely why I would use Rails in the first place, I think -- and why, when I use Sequel::Model instead of ActiveRecord, I still end up using has_many and belongs_to, rather than one_to_many or associate. Semantics are important. Syntactic sugar (or vinegar) is important.> @David: Lots of plugins mixin to ActiveRecord::Base, or override > methods. Are you going to volunteer to help all those maintainers fix > them? And add nasty checks everywhere to see if Base is defined; else > use the new "better" name?Those "nasty" checks could be on Rails.version. And for the third time now, those plugins would continue to work. ActiveRecord::Base would be exactly the same as ActiveRecord, until a major breaking change (Rails 3?). Now, Xavier mentions an interesting option that may satisfy both> camps. Create an ApplicationModel like ApplicationController.Yes, that would satisfy me. Not that I was particularly passionate about this in the first place. I just wanted to demonstrate that this could be a purely cosmetic change, with little or no impact on compatibility. Since I actually don''t care, I guess I''m just making noise. I''ll stop. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
I still like Base both as a name for what the thing is, it''s the base class of Active Record, and for its reusability across different frameworks, like ActionController::Base, ActiveResource::Base, etc. I see no gain in changing it nor do I think any of the proposed alternative names are better (i.e. Resource or Model). --~--~---------~--~----~------------~-------~--~----~ 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 Wed, Oct 15, 2008 at 11:34 PM, DHH <david.heinemeier@gmail.com> wrote:> I still like Base both as a name for what the thing is, it''s the base > class of Active Record, and for its reusability across different > frameworks, like ActionController::Base, ActiveResource::Base, etc.But we''ve ApplicationController < AC::Base to put common stuff. Modulo de impedance in the docs I explained, don''t you think ApplicationModel < AR::Base makes sense for the same purpose in Rails? --~--~---------~--~----~------------~-------~--~----~ 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 Wed, Oct 15, 2008 at 23:49, Xavier Noria <fxn@hashref.com> wrote:> > On Wed, Oct 15, 2008 at 11:34 PM, DHH <david.heinemeier@gmail.com> wrote: > > > I still like Base both as a name for what the thing is, it''s the base > > class of Active Record, and for its reusability across different > > frameworks, like ActionController::Base, ActiveResource::Base, etc. > > But we''ve ApplicationController < AC::Base to put common stuff. Modulo > de impedance in the docs I explained, don''t you think ApplicationModel > < AR::Base makes sense for the same purpose in Rails?Nothing prevents people from writing: class ApplicationModel < ActiveRecord::Base self.abstract_class = true end class User < ApplicationModel # ... end --~--~---------~--~----~------------~-------~--~----~ 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 Wed, Oct 15, 2008 at 7:04 PM, Mislav Marohnić <mislav.marohnic@gmail.com>wrote:> On Wed, Oct 15, 2008 at 23:49, Xavier Noria <fxn@hashref.com> wrote: > >> >> On Wed, Oct 15, 2008 at 11:34 PM, DHH <david.heinemeier@gmail.com> wrote: >> >> > I still like Base both as a name for what the thing is, it's the base >> > class of Active Record, and for its reusability across different >> > frameworks, like ActionController::Base, ActiveResource::Base, etc. >> >> But we've ApplicationController < AC::Base to put common stuff. Modulo >> de impedance in the docs I explained, don't you think ApplicationModel >> < AR::Base makes sense for the same purpose in Rails? > > > Nothing prevents people from writing: > > class ApplicationModel < ActiveRecord::Base > self.abstract_class = true > end >Nothing prevents people, but ApplicationController is provided by the default Rails skeleton, and used by "script/generate controller". Having the same for ActiveRecord isn't entirely unreasonable, and wouldn't really require touching ActiveRecord -- just Rails generators. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
> Nothing prevents people, but ApplicationController is provided by the > default Rails skeleton, and used by "script/generate controller". > > Having the same for ActiveRecord isn''t entirely unreasonable, and wouldn''t > really require touching ActiveRecord -- just Rails generators.Controllers have a much closer bond than models do. The reason for ApplicationController is specifically to deal with the common scenario of filters that needs to be shared across all controllers and, as a distant second, shared functionality of the standard variety. In other words, application-specific behavior that doesn''t fit into ActionController::Base. I''ve personally never felt the desire to include any such application- specific behavior for all my Active Record models. And unlike Action Controller, Active Record doesn''t have a monopoly on the model space in a Rails application (just think Active Resource or vanilla Ruby objects). I frequently have non-AR models, so ApplicationModel would be misleading. So I see the comparison, but I don''t think it''s valid in this case. Controllers and models are of a different breed and need different care. --~--~---------~--~----~------------~-------~--~----~ 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, Oct 16, 2008 at 10:12 AM, DHH <david.heinemeier@gmail.com> wrote:> >> Nothing prevents people, but ApplicationController is provided by the >> default Rails skeleton, and used by "script/generate controller". >> >> Having the same for ActiveRecord isn''t entirely unreasonable, and wouldn''t >> really require touching ActiveRecord -- just Rails generators. > > I''ve personally never felt the desire to include any such application- > specific behavior for all my Active Record models. And unlike Action > Controller, Active Record doesn''t have a monopoly on the model space > in a Rails application (just think Active Resource or vanilla Ruby > objects). I frequently have non-AR models, so ApplicationModel would > be misleading.I see your point. I often reopen AR::Base (or include something, it doesn''t really matter). In my experience that''s all sharing I need. ApplicationModel would suggest there''s a root class for the M layer, and that''s not going to work. Yeah. So upon reflection what I miss is a root for AR models in the application, and ApplicationModel is a misleading name for it. Reopening AR::Base does the job, but I''d just prefer a well-defined application specific class provided by the skeleton and generators so you know where people are going to put shared stuff, instead of carefully inspecting config/initializers and lib (say). Given the mismatch such a new root class would imply for the documentation I am unsure it is worth the trouble, I can''t think of a good proposal for this at this moment. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---