Require

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Require

Mark Hamburg-4
on 7/25/04 1:10 PM, Rici Lake at [hidden email] wrote:

> There was quite a discussion about cyclic import at some point. How
> does one handle mutually dependent packages? It is not always easy to
> eliminate this. Indeed, to my mind this is the semantic difference
> between "require" and "import": require defines a dependency (this
> package won't work without the other one) while import defines a
> need:(I'm about to use this package, I need it now.) Of course, that is
> just me, and the particular words are not important, but there do seem
> to be two use cases.

The Oberon System demonstrated that you can do quite a bit without cyclic
import. The fallback usually involves having one module register itself with
the other module after importing it. This mechanism is referred to as an
upcall in Oberon.

Mark


Reply | Threaded
Open this post in threaded view
|

Re: Require

Diego Nehab-3
Hi,

> The Oberon System demonstrated that you can do quite a bit without cyclic
> import. The fallback usually involves having one module register itself with
> the other module after importing it. This mechanism is referred to as an
> upcall in Oberon.

I agree. How often do two or more modules mutually need each other,
*while they are being loaded*?

[]s,
Diego.

Reply | Threaded
Open this post in threaded view
|

Re: Require

Rici Lake-2

On 26-Jul-04, at 12:43 AM, Diego Nehab wrote:

The Oberon System demonstrated that you can do quite a bit without cyclic import. The fallback usually involves having one module register itself with the other module after importing it. This mechanism is referred to as an upcall in Oberon.

I agree. How often do two or more modules mutually need each other,
*while they are being loaded*?

Practically never, I think. The case where there is a cyclic dependency at runtime is rare, too, but it comes up from time to time. It can be resolved easily if the package table can be created before it is filled in. Having two different interfaces means that no-one is forced to use the one which allows circularity.

The Oberon mechanism, and similar ones, do indeed demonstrate that a wide variety of workarounds are possible. But they do not demonstrate that such workarounds are easy :)


Reply | Threaded
Open this post in threaded view
|

Re: Require

Asko Kauppi-3
In reply to this post by Edgar Toernig

Also, sometimes it might be nice to build both C and Lua side in the same dll. I've done this -just for fun- for the LuaX serial module. It sort of simplifies maintenance (one module = one file) but I'm not enforcing this by any means. Just trying out.

Once this discussion settles & reaches some common understanding, I'd be delighted to try out a 'standard' linkage method for LuaX. Until then, I'll stick with my own.

-ak

ps.
Also module placement (file system) issues will arise. I for one have found it hard to match LuaX into the standard Posix /usr tree. It really doesn't devide into include, lib etc. so easily.


26.7.2004 kello 05:08, Edgar Toernig kirjoitti:

 To have the possibility to wrap any library with a Lua script is IMHO
crucial.  But force it?  No!  Just think about statically linked
libraries...


Reply | Threaded
Open this post in threaded view
|

Re: Require

Adrian Sietsma
Asko Kauppi wrote:
Also, sometimes it might be nice to build both C and Lua side in the same dll.

major point.
we have been embedding lua script into windows dll's as resources. this massively simplifies packaging and distribution of hybrid c/lua libraries.
this has an impact for naming / require / packaging issues

Adrian

Reply | Threaded
Open this post in threaded view
|

Re: Require

Diego Nehab-3
Hi,

> we have been embedding lua script into windows dll's as resources. this
> massively simplifies packaging and distribution of hybrid c/lua libraries.
> this has an impact for naming / require / packaging issues

As long as the mapping between names and loaded Lua chunks or names and
C entrypoints can be overriden, everything is possible.  Someone might
link a bunch of libraries into the executable itself, along with their
Lua part and create his own mapping function to sort things out. It
doesn't matter.

In the user's point of view, all require() needs is a way to find
something to run and return.

In the mixed library's developer's point of view, all he needs is that
his Lua code be able to find the C entrypoint, or that his C entrypoint
be able to find the Lua code.

[]s,
Diego.

Reply | Threaded
Open this post in threaded view
|

Re: Require

Asko Kauppi-3
In reply to this post by Adrian Sietsma

They can also be embedded as simple C tables, which is an OS-independent way. This requires recompilation, of course, which your res approach does not (only linkage).

-ak

27.7.2004 kello 22:52, Adrian Sietsma kirjoitti:

 Asko Kauppi wrote:
Also, sometimes it might be nice to build both C and Lua side in the same dll.

major point.
we have been embedding lua script into windows dll's as resources. this massively simplifies packaging and distribution of hybrid c/lua libraries.
this has an impact for naming / require / packaging issues

Adrian



12