From: Austin Ziegler Date: 2005-09-30T12:13:33+09:00 Subject: Re: Require Namepaces and RubyGems' effect on LoadPath problem On 9/29/05, TRANS wrote: > On 9/29/05, Austin Ziegler 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 * halostatue@gmail.com * Alternate: austin@halostatue.ca