Re: as so often before require()

["Peter Hill" <corwin@...>]

Peter:
> It makes reference to LTN7 (modularising by returning a table) which is
> something I just naturally do myself when using "dofile".

Wim:
> LTN7 does not mention _returning_ the interface as a table but instead
> gives examples where a package plugs its global interface directly into
> the global namespace.

Whoops! My mistake. I just sort of assumed that... as a combination of a few
statements made plus some personal assumptions (like, what is the point of
"modularising" when you then go and attack the global namespace?). I shall
check the reference first next time. :-(


Wim:
> Instead of directly returning a table, a "LTN11" package returns a
> _function_, that installs the package in a given public table (as its
> first argument.)

I'm still not sure here why you return a function and not just a module
table? Eg:
    Complex = import("complex.lua")


Peter:
> ... it might simply be more appropriate to wrap their import with a global
> table and let them alter that? The "import" call would then return that
> table.

Wim:
> The trouble is that packages will need some "common" globals like print
> (and even probably import itself), etc.  I tried some scenario's but in
> the end globals table manipulation didn't fit the bill.

Agreed. And I also realised that it restricts the function names that the
module can define. Ie, if you wanted to define "Complex.print" simply as a
function named "print" inside the global space of the "Complex" package it
would conflict with the real 'print'.


Peter:
> Rather than returning an error, "import" should probably store the
> metatable and enable it upon unlocking the stub.

Wim:
> ?  Do you think you can handle more dependencies than the current
> proposal? That would be worthwhile.  It's just that I don't understand
> your remark...

What I meant is that in the current proposal any premature accesses to the
table representing the package being defined is considered a cyclic
reference. I was thinking that setting the metatable for the package table
should be excluded from that... but then again, what if the package
definition sets that metatable itself? I take back my suggestion.

Cheers,
Peter Hill.