[Nitro] Build scripts as modules or plain scripts

[transfire at gmail.com]

gabriele renzi wrote:
> transfire at gmail.com ha scritto:
>
> > Of course this effectively puts encapsulation, at least at the top
> > level, on a per-file basis. But in many respects that seems kind of
> > nice. It increases flexability and reduces configuration complexity.
> >
> > So what do your think? Is this technique worth promoting? Or am I being
> > silly and should just wrap all my scripts in modules?
>
>
> first: adding the "as_foo" just adds useless complexity, imho, just load
> a module and include id when needed.

That's true. I was primarily just highlighting the potential of this
approach with those methods.

> Then, if you just add
>
>   and a directory is a module, too so that
>    require 'foo'
>   loads module Foo
>   and
>    require 'foo/bar'
>   requires module Foo::Bar
>
> and you have the python's import system, which is a very good thing imo
> and could reduce ruby's stdlib size of a 1/2% :)

interesting... some thoughts

* it would require all core extensions be prefixed with '::' (eg.
::Kernel).

* would toplevel need a name, eg. ::Toplevel. how else could we load
anything to it? or maybe we shouldn't be able to?

* what if two libs have the same path but are in different load paths
(a la gems) -- though I suppose a smart developer would make sure that
didn't happen. For example, all things Facets are in
{load_path}/facets/.

* being able to assign the name seems much more flexible though --this
would prevent potential name clashes of items that might share the same
path but are within different load paths. (I suppose we could have two
different methods).

* if we added #new to module, would we even need to bother with classes
directly? Ie.

  class Module
    def new(*args,&blk)
      Class.new{ include self }.new(*args,&blk)
    end
  end

(hmm... how would we access the underlying class?)

Thoughts?

btw. what does python use for the name of its "require" method?

T.