Re: [jamboost] Baked module global semantics

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-03-27 11:40:24

On 2002-03-27 at 01:42 AM, david.abrahams_at_[hidden] (David Abrahams) wrote:

>Every module has its own variable space. Within a module, variable
>values and settings are exactly as though all scopes inside other
>modules have been eliminated. This includes the global module. Thus, no
>module ever has access to globals or locals from another module. The
>only way to pass values across module boundaries is via rule arguments
>and return values. Example:

Ah, yes, I understand that. I was still trying to parse your previous messages
:-\

>module A
>{
> x = 1 ; # x is global in A
> local y ;
>
> module B
> {
> ECHO $(x) ; # prints blank line
> local x = BANG ;
> y = BOOM ; # y is global in B
> rule printxy { ECHO $(x) $(y) ; }
>
> module A
> {
> y = 2;
> ECHO $(x) ; # prints 1
>
> local y = 3 ;
> ECHO $(y) ; # prints 3
> B.printxy ; # prints BANG BOOM
> }
> }
> ECHO $(y) ; # prints 2
> B.printxy ; # prints BOOM
>}
>
>I think this will considerably simplify the code for handling module
>variables. Feedback, please!

I see some advantages to this approach:

- It forces better interfaces on modules instead of communication/setup with
variables.
- The semantics are close to class/object ones I'm familiar with :-)

Question; What are the semantics of "import" in this case? I the previous
message you implied that variables get affected when importing but the docs
only talk about rules. From my current intuition of this, the variables don't
get affected, and the imported rules access their corresponding modules
variables.

-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq - Grafik666_at_AIM - Grafik_at_[hidden]