Namespace pollution in Rails

[Leslie Viljoen]

Hi all

I posted a while back about my Rails project having a class called Property
which clashed with the Glue module at Textdrive. They have now removed
the Glue gem and I have changed the name of my class so all is well, but I
still would like to understand how Glue took over the default namespace like
that.

When I ran my script/console on Textdrive I got:

Loading production environment.=> [Glue, PP::ObjectMixin, Base64:eprecated, Base64, Kernel]

After glue was removed:
Loading production environment.=> [Base64:eprecated, Base64, Kernel]

How did it take control of the default namespace (and only when Rails was
loaded?) Using irb never gave this problem, and Rails never refers to Glue
directly.

Les

 

[Trans]

Are they using Gems?

T.

 

[Trans]

This shoud be a lesson.

Unless you are specifically creating a general purpose class or module
which can be required INDEPENDENTLY, for all the world to use in their
projects (for example a OrderHash), you should NOT load your classes
and modules into that space.

T.

 

[Leslie Viljoen]

This shoud be a lesson.

Unless you are specifically creating a general purpose class or module
which can be required INDEPENDENTLY, for all the world to use in their
projects (for example a OrderHash), you should NOT load your classes
and modules into that space.

T.

Yes, they are using Gems.

I agree with what you are saying, in fact I think libraries that
do this should be removed - and that is what they have done
in response to my requests at Textdrive. Strangely, I installed
the latest version of Nitro and Glue and both irb and the
Rails console environments were inaffected. It must have been
an older version of Glue, but it still beats me how this came about.
Irb showed no pollution, only when running a Rails app did there
suddenly appear a loaded Glue module.

This is why I am so curious about it - how did Glue get itself loaded?

I'd like to be able to circumvent such things in future, it is
impossible to code around every possible class people dream up
and Glue even modified the default String class!

 

[Trevor Squires]

Hi Leslie,

I encountered a Glue conflict as well a while back. I believe it's
something to do with the html_scanner library that is included in rails
(action_controller/vendor).

This rails patch may not be specific to your own issue but it does
(IMHO) give an indication of why the glue gem's files are getting
loaded by rails:

http://dev.rubyonrails.org/ticket/2255

Regards,
Trevor

 

[Trans]

I agree with what you are saying, in fact I think libraries that
do this should be removed - and that is what they have done
in response to my requests at Textdrive. Strangely, I installed
the latest version of Nitro and Glue and both irb and the
Rails console environments were inaffected. It must have been
an older version of Glue, but it still beats me how this came about.
Irb showed no pollution, only when running a Rails app did there
suddenly appear a loaded Glue module.

This is why I am so curious about it - how did Glue get itself loaded?

Unfortuately require doesn't record absolute paths (fixed in 1.9) and
Gems can have subtle effects on how things get required. So between the
two there's a name clash somewhere.

That seems to be a bad tendency of such "full-stack" solutions. They
tend to think they own the entire relam of namespaces. I recall once
someone suggesting Ruby use variable's for module loads rather then
static constants. That would have helped, but such is life. Presently
I'm working with George to help seal up issues on the Glue side as time
permits.

I'd like to be able to circumvent such things in future, it is
impossible to code around every possible class people dream up
and Glue even modified the default String class!

Well, thats' not neccessarily bad. As long as one's only adding methods
(and documenting them!) it should be okay. The serious problems araise
when one changes pre-established behaviors. That's why there is such a
clamor for namespace selectors these days.

T.

 

[Leslie Viljoen]

Unfortuately require doesn't record absolute paths (fixed in 1.9) and
Gems can have subtle effects on how things get required. So between the
two there's a name clash somewhere.

That seems to be a bad tendency of such "full-stack" solutions. They
tend to think they own the entire relam of namespaces. I recall once
someone suggesting Ruby use variable's for module loads rather then
static constants. That would have helped, but such is life. Presently
I'm working with George to help seal up issues on the Glue side as time
permits.

From what I have seen, these functions are in the top level
namespace as a convenience, and one we can't live without
because in Rails, if I had to type

Well, thats' not neccessarily bad. As long as one's only adding methods
(and documenting them!) it should be okay. The serious problems araise
when one changes pre-established behaviors. That's why there is such a
clamor for namespace selectors these days.

T.

That's not bad as long as you have the option to not include
a module that does this. If not, your classes get heavier and
heavier as they get larger and larger, and if you want to
add to them yourself you find yourself increasingly unable
to find a name that remotely describes the functionality you
are adding.