On Jun 11, 3:51 ¨Âí¬ ÐèéììéÇá÷ìï÷óë¼ãíäêáãëò®®®Àçïïçìåíáéì®ãïí¾
wrote:
> On Sat, Jun 11, 2011 at 9:12 PM, Intransition <transf... / gmail.com> wrote:
>
> > This idea of course presents backward compatibility issues, but it is
> > a way to do it that actually improves the robustness and efficiency of
> > the load system.
>
> 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.

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

> Do I want a local or a global file? What's the syntax for a global
> require, again? And it's almost, but not entirely, completely unlike
> accessing nested constants (Module::Class vs ::file).
>
> 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.

> On the flip side, require and require_relative make it completely
> clear that I load either globally or in relation to my source files
> *without* having to remember what a particular bit of line noise
> means.
>
> If the issue is that you have to type so much more, set up a macro in
> your favourite editor. Or if you happen to use AutoHotKey:
> ::r#::require
> ::rr#::require_relative

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