Re: RFC - One word alias for require_relative

On Jun 11, 6:24=A0pm, Phillip Gawlowski <[e-mail]>
wrote:
> On Sat, Jun 11, 2011 at 11:08 PM, Intransition <[e-mail]> wrot=
e:
>
> >> 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=3D>'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"
> =3D> true
> >> require "./ostruct"
>
> This is not Ruby's OpenStruct library.
> =3D> 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.