Re: Renaming Journey and avoiding libraries with common noun names

[Gary Weaver]

Probably a stupid solution, but rather than suggesting non-common noun names, why not suggest to put it in a module like Rails::Journey (or whatever would make sense)?

That alone doesn't solve your issues, but if you don't mind really messing with the way Rails resolves constants, you could use something like these:
https://github.com/garysweaver/classmeta/blob/v0.1.0/lib/classmeta/class_registry.rb
https://github.com/garysweaver/classmeta/blob/v0.1.0/lib/classmeta/dependencies.rb

(not the classmeta gem, but that method of placing a layer of constant resolution between your app and rails.)

That isn't efficient and still doesn't help, but if you took that yet another step further, you could change autoloading such that it keeps track of whether the class was loaded locally or not, and if it was, it would use your Journey class, otherwise it would use some other gem's Journey. You could generify the gem and call it StevePerry or maybe just Perry. Hmm.. might do that later.

Your concern is sane, but attempting to change the developer tendency to call things by great band names seems like it might be a problem.

As usual though, I'm probably wrong. Way wrong. In the worst of ways.


On Wednesday, September 19, 2012 4:00:12 PM UTC-4, Sam Lown wrote:

Hi all,

I know this is a long shot, but could renaming the "Journey" module please be considered by those in a position to support it?

I've written an issue on this in the journey repo also: https://github.com/rails/journey/issues/49

Essentially our project has a model named Journey, the same as Rails 3.2's new routing driver. As a consequence we can no longer upgrade from 3.1, without changing 'journey' throughout our project. 

Given that our project pretty much consists of journeys, or Journey models, for which there is practically no other name in the English language, I'm sure you can appreciate how much of a PITA refactoring would be for us.

Looking through Rails 3.2's fresh Gemfile.lock, its clear there are very few common nouns used to name libraries, the exception being Rack, which maybe annoyed a few data center managers but little more.

As a long term strategy, I'd like to suggest avoiding generic or common nouns for projects, so as to avoid conflicts like this.

Cheers, sam

[Gary Weaver]

On Friday, September 21, 2012 12:09:23 PM UTC-4, Gary Weaver wrote:

or maybe just Perry.

Darn, that name was already taken. Looks like a nice project: https://rubygems.org/gems/perry

[Gary Weaver]

On Friday, September 21, 2012 12:09:23 PM UTC-4, Gary Weaver wrote:

That isn't efficient and still doesn't help, but if you took that yet another step further, you could change autoloading such that it keeps track of whether the class was loaded locally or not, and if it was, it would use your Journey class, otherwise it would use some other gem's Journey. You could generify the gem and call it StevePerry or maybe just Perry. Hmm.. might do that later.

Ok, this is not done/working yet, but is a start. Was thinking that maybe looking at caller stack might be better to attempt to determine whether class is being referenced locally, so not messing with autoload. However, I have a feeling this won't work unless the Journey constant is uncached on each reference. My daughter is extremely bored waiting on me currently, so gotta run for now:
https://github.com/garysweaver/constance

[Robert Pankowecki]

Essentially our project has a model named Journey, the same as Rails 3.2's new routing driver. As a consequence we can no longer upgrade from 3.1, without changing 'journey' throughout our project. 

Why don't you rename it to MyProject::Journey and reimplement model_name method ?

class MyProject::Journey

  def self.model_name

    @model_name ||= ActiveModel::Name.new ::Journey

  end

end

I am not sure if that would work perfectly but you can give it a try.

Robert Pankowecki

http://robert.pankowecki.pl/

[Gary Weaver]

Got constance working and it is sweet like candy (like old-tyme candy back before they knew how to make candy, so forgive me if it sucks). This might solve the common-noun constant problem. Try it out and let me know.
https://github.com/garysweaver/constance

[Gary Weaver]

Looks like it still needs some work. It works with resolving other classes, but even if I try to remove Journey from the class cache with:
ActiveSupport::Dependencies::Reference.clear!

that doesn't work. Oh well, sorry. It makes a decent dependency debugger though.

[Gary Weaver]

Ah. Wasn't thinking that the constants in ActiveSupport::Dependencies::Reference don't include everything. :)

Needed to store the class for later retrieval and then:
Object.send(:remove_const, :Journey)

I think may be fixed in current version of Constance gem. Try:
Constance::Resolver.will_replace(Journey)

Unfortunately the example search regexps on the caller stack may be inadequate because lib is in just about every gem so would need to prefix with your app name.