Rails core - Sep 2012 - Renaming Journey and avoiding libraries with common noun names

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

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-core/-/Lq5um1WFO2UJ.
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.

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
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-core/-/Bds_FcnjbngJ.
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 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

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-core/-/3f9qE1OZ9ogJ.
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 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

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-core/-/xrA6pNSuByYJ.
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.

>
> 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/

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-core/-/lCa3ywU0YhAJ.
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.

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


On Saturday, September 22, 2012 9:41:52 AM UTC-4, Gary Weaver
wrote:
>
>
>
> 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
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-core/-/hX0amORd7TMJ.
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.

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.

On Thursday, October 4, 2012 11:37:11 PM UTC-4, Gary Weaver
wrote:
>
> 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
>
>
> On Saturday, September 22, 2012 9:41:52 AM UTC-4, Gary Weaver wrote:
>>
>>
>>
>> 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
>>
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-core/-/wrPfAuf_58EJ.
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.

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.

On Friday, October 5, 2012 12:16:10 AM UTC-4, Gary Weaver
wrote:
>
> 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.
>
> On Thursday, October 4, 2012 11:37:11 PM UTC-4, Gary Weaver wrote:
>>
>> 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
>>
>>
>> On Saturday, September 22, 2012 9:41:52 AM UTC-4, Gary Weaver wrote:
>>>
>>>
>>>
>>> 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
>>>
>>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-core/-/DaL-CBR2yoEJ.
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.