Re: RFC - One word alias for require_relative

On Sat, Jun 11, 2011 at 11:08 PM, Intransition <[e-mail]> 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.

>> Especially since your idea introduces a *lot* of mental overhead on my p=
art:
>
> 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.

>> 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]

> 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.

> 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.

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.

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"?


--=20
Phillip Gawlowski

A method of solution is perfect if we can forsee from the start,
and even prove, that following that method we shall attain our aim.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Leibnitz