Re: Require Namepaces and RubyGems' effect on LoadPath problem

On 9/29/05, TRANS <[e-mail]> wrote:
> On 9/29/05, Austin Ziegler <[e-mail]> wrote:
>> That doesn't change that the primary purpose of namespaces in XML is
>> to solve a real problem ... that doesn't exist in Ruby. Frankly, what
>> you've written is code in search of both a problem and a solution.
>> It's neat, but ultimately useless for anything meaningful or helpful.
> "both a problem and a solution"? Come on Austin that's hyperbole,
> fully illogical.

Sure, it's hyperbole. But I also find it far more logical than this
idea.

> Do you think I'd be wrting the code if I didn't have a problem?

I think you're writing the wrong code for your problem -- if you indeed
have a problem. As to answering that question, I think you often end up
writing code or coming up with ideas for solutions to problems that you
perceive ... that don't exist for anyone else.

> I have a very real problem --and a solution as well.

I don't actually think you've *got* a problem; I think you *think* you
have a problem. I think that you've tried to muck with require twice and
come up with solutions that are worse than the so-called problems (this
and your require 'nil?' sort of behaviour).

> Why you so desparetely want to shun this altogether I have no idea,
> but I wonder if you are so hung up on RubyGems that you don't like the
> idea of anything that might play in its ballpark. Namely overriding
> require to do something USEFUL.

Um. That's the point, Trans. This isn't useful. This solves something
that *you* think is a problem, but that I, at least, don't think is a
problem in the least. Why is it a problem for people to fully specify
things (e.g., modules/foo and classes/foo) or fix your structure to be a
bit more intelligent overall?

You're trying to solve a human engineering problem -- namely your
problem -- with a computer engineering solution. It's the wrong
solution.

>>>> I still don't understand how this namespace proposal improves
>>>> things, other than to reduce typing. Can you give an example?
>>> I use it to organize a very large library. I've organized the lib
>>> according to principles that make sense for development --in this
>>> case it's a collection of general purpose libs so I've put classes
>>> in one directory, modules in another, etc. But I don't want the end
>>> user to have to "path down" so far, so the namespace allow all the
>>> folders to be grouped together. So intead of:
>> Then it may make more sense for you to reorganise your lib for
>> development. Or maybe -- just maybe -- it's time to split nano and
>> mega into different release collections.
> Yea, right. You really just don't get it.

I get it -- I also get that you're wanting to modify Ruby to match your
view of Ruby ... which I don't think others view. Did you notice that
*no one* has responded to your namespaces posts on ruby-talk? This
really does seem to be something that exactly one person has a problem
with. What additionally bothers me about this is that you first raised
it in ruby-core before bothering to see if anyone *else* was having a
similar problem on ruby-talk.

>> If that's not desirable, then reorganise the files dynamically during
>> packaging. The Rakefile that I use to package PDF::Writer does
>> *exactly* that with the .tar.gz files. I'd like to be able to get
>> into that level of rewriting the internals of .gems, but I haven't
>> yet asked for it.
> You mean to tell me you rearrange the files just before distribution?
> That's sounds like a pain in the rear. How do you handle the change in
> require paths? Don't tell me your Rake file searches and replaces them
> all too.

In fact, it does. It does so in a limited fashion right now
(specifically for creating the demo programs package for PDF::Writer),
but I actually can do quite a bit of smart editing on the packaging. It
might also be a pain in the rear, but it doesn't leave me asking for
changes in Ruby's core, either.

>>> Morover, it makes it easy to add aliases. For instance this could
>>> work too:
>>>
>>>   mylibs/foo.rb
>>>   mylibs/bar.rb
>>>
>>> As things stand there is no way to do this. One could use symlinks but
>>> you'd have to maintain them and they are not cross-platform.
>> Again, code in search of a reason and use. Why would you *want* to do
>> this? It ends up *defeating* Ruby's load-protection mechanisms (e.g.,
>> if mylib/foo and mylibs/foo are the same thing, they *will* be loaded
>> twice because they appear to be unique files).
> No, b/c Ruby only requires the real name, after it's been converted,
> not the namespace.

Hm. That may be, which makes this less *dangerous*, but no less
confusing to other users -- and that's the main reason I'm opposed to
this.

> There are a number of reasons. In the exmple above it is to offer a
> puralized alternate --not a big deal, but if its easy enough...

Again, I don't think that's really ideal or sufficient reason.

> More importantly perhaps some files have been moved around, all your
> end users will now have to alter there programs to the new locations.
> With this you could offer backward compatibily for a while, throwing a
> warning until people had enough time to make the changes.

I could actually offer backward compatibility and deprecation with:

  # old/foo.rb

  unless $old_foo_required
    warn "require 'old/foo' has been deprecated, use require 'new/foo'."
    require 'new/foo'
    $old_foo_required = true
  end

This is something that I do mostly with methods and objects (and
constants in color-tools). I also *clearly* document which items are
public -- and I don't muck around with those. I will grant that it's a
bit *harder* with something like nano or mega, but I believe that if
you're going to offer something that comprehensive, then it's *you* that
needs to go the extra mile, not the Ruby core.

> Another interesting possibility that you probably have not considered
> is that it could help with packaging on different systems. [...]

I do not believe it will help with packaging in the least and will only
increase confusion.

-austin
--
Austin Ziegler * [e-mail]
               * Alternate: [e-mail]