On Mon, Mar 16, 2009 at 6:34 PM, Ryan Angilly <[email protected]> wrote:

>
> http://m.onkey.org/2007/12/9/namespaced-models


This one begins with a comment of "I don't really understand why people use
namespaced models."  That's not really a compelling argument.

There is a reason we namespace things in general. Otherwise, why have these
top-level modules like ActiveRecord in the first place?

http://stackoverflow.com/questions/601768?sort=oldest


The main argument here, other than the strictlyuntyped link, is that you
can't do it in the database -- so what? You can't define methods on a
database table either, yet we do it in Rails. Database tables can't be
polymorphic all by themselves, but Rails adds that. And the naming
convention could ensure that while it is a flat namespace of DB tables, the
namespaced ones will never conflict with anything outside that namespace.


> http://www.strictlyuntyped.com/2008/08/activerecord-can-haz-namespaces.html


This describes bugs in the current implementation.

So, it looks like the biggest argument not to use namespaced models is that
they don't work very well in Rails.

Really?

Isn't that a bit like arguing we shouldn't have started using REST, because
it didn't work very well in Rails? That was seen as a bug to be fixed, or a
feature to be added, not a hazard to be avoided.

The other argument that seems to be tossed around a lot is that you can put
things into a subfolder. Somehow, I think that would be less useful -- now
the convention of filename->class name is broken, and I can't get a list of
all top-level model classes by looking in app/models. It also doesn't
address the real reasons you might use namespaces.

If anyone can offer any reason namespaces shouldn't be done, other than that
Rails doesn't do them well, that'd be a more interesting discussion.

Otherwise, it's circular reasoning. We shouldn't fix Rails namespacing,
because namespacing is a bad idea, because Rails doesn't do namespacing
well, because no one's fixed it yet.


<http://www.strictlyuntyped.com/2008/08/activerecord-can-haz-namespaces.html>
> On Mon, Mar 16, 2009 at 6:16 PM, José Valim <[email protected]> wrote:
>
>>
>> Hi guys,
>>
>> Before opening a ticket, I want to be sure if this is a bug or not.
>> Example:
>>
>>  class User < ActiveRecord::Base
>>  end
>>
>>  class Admin::User < ActiveRecord::Base
>>  end
>>
>> And then:
>>
>>  class Account < ActiveRecord::Base
>>    belongs_to :user
>>  end
>>
>> When I was calling Account.new.build_user, it was trying to create a
>> new Admin::User because the default class_name is just "User". To fix
>> the problem, I had to do:
>>
>>  class Account < ActiveRecord::Base
>>    belongs_to :user, :class_name => '::User'
>>  end
>>
>> It also has problems in the opposite way:
>>
>>  class User < ActiveRecord::Base
>>  end
>>
>>  class Admin::User < ActiveRecord::Base
>>  end
>>
>> And then:
>>
>>  class Admin::Account < ActiveRecord::Base
>>    belongs_to :user
>>  end
>>
>> Sometimes Admin::Account.build_user is trying to build a ::User and
>> other times ::Admin::User, because, again the default class_name is
>> just "User".
>>
>> My opinion is that in the first case, the class name should be by
>> default "::User" and in the second it should be "::Admin::User".
>>
>> The thing is, since the patch comes in, it will break apps that are
>> relying in this wrong behavior. The good point is that the error will
>> be raised when the application starts. The way it's now, takes quite
>> sometime for you to discover that Account was trying to build a
>> Admin::User instead of User.
>>
>> Are you in or out for this change?
>>
>> Regards,
>>
>> José Valim.
>>
>>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
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 [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to