From: Intransition Date: 2011-06-12T08:42:38+09:00 Subject: Re: RFC - One word alias for require_relative On Jun 11, 6:24 pm, Phillip Gawlowski wrote: > On Sat, Jun 11, 2011 at 11:08 PM, Intransition wrote: > > >> If it breaks backwards compatibility, it's neither effective nor > >> robust, I'd say. > > > They are different. Of course it's not robust if you are mixing two > > incompatible systems. Obviously we wouldn't do that. > > Mu. Address the point I made. Then call it #another_way_to_load_a_ruby_file or #awtlarf to meet IIias' 7-letter requirement;. Whatever. It's beside the point. > >> Especially since your idea introduces a *lot* of mental overhead on my part: > > > Not really, it similar enough to overhead that we use for Ruby already > > in referencing constants. I mean really, it's `::` and `package- > > name:file-path` that's all there is to know. > > require # works globally > require_relative # works relative to current working directory > > What these methods do is *encoded in the method name*. I don't have to > remember *a thing*, since the method tells me what it does, and it > even works when require[_relative] loads from a variable. You still have to remember the name of the method. Moreover my system does things yours does not. So to be fair you would need another method or two, and a hash option too, e.g. require 'ostruct', :library=>'ruby' > >> And running non "::require"-aware code leads to fun bugs and security > >> issues (imagine a "ostruct" file in the load path that wipes your > >> filesystem. The joys...). > > > That can already happen, btw. Very easily in fact. But again you are > > suggesting mixing two incompatible systems. > > Not without "." in the loadpath it can't: > PS C:\temp> irb>> require "ostruct" > => true > >> require "./ostruct" > > This is not Ruby's OpenStruct library. > => true>> exit > > PS C:\temp> cat .\ostruct.rb > puts "This is not Ruby's OpenStruct library." > PS C:\temp> ruby -v > ruby 1.9.2p180 (2011-02-18) [i386-mingw32] What's your point? I don't see how that has anything to do with what you said. > > No, that's not it. You missed the big benefit here. By specifying the > > package-name in the require, we can guarantee the origin of the file. > > No, we can't. Look up is still along the path, and something that is > named identically within the loadpath that gets loaded first still > blows up in your face. That's not it. The suggestion I am making moves beyond the simple path system Ruby now uses. It would require that Ruby understand packages. So it's not "still along the path". > > As things are today, a gem author could readily play havoc with the > > load system --which is why isolation systems sprung up, like isolate > > and (partially) Bundler. > > Which your system doesn't mitigate against at all. And it cannot, ever > (nor does Bundler: It is a poor man's version and dependency control). > Once code is on a machine, it can do whatever it wants. Ruby just > makes it easier to modify its own classes, but the vector is still > there: external code executed locally. Yes it does. I use it all the time. I wrote such a system and use if for development. > Without making gem signing the default, and have Ruby / RubyGems load > *only* signed source files, you have no idea who created the code > you've downloaded. And even then you have to trust the certificate, > and that the private key with which the code was signed wasn't > compromised somehow. You're now talking about another subject. > Without auditing code, you have no idea what the code does to your > machine, and who prevents anyone from claiming "I'm part of Ruby's > namespace"? Ruby.