Re: Language module support added

On Sunday 28 September 2003 18:14, you wrote:
> Adriaan de Groot wrote:
> > OK. The collision in namespace between module names and variables is a
> > pain, though, since it means thinking up some contorted module name
> > for the libtool module (libtoolmod is what i've settled on, since it's
> > not a language module which should be named *lang).
>
> Did you see my suggestion to use "m_<module-name>" for the scope?  Thus
> it would be "m_d" for the D language and "m_libtool" for the libtool
> module.  I already have a patch for this, waiting for a positive
> response before I send it out.

Yes, I saw it and didn't take time to think it through yet - I was trying to 
write recipes instead. What would the filename be? Personally, I'd like to be 
able to :import d without it conflicting with variable $d at all - that's 
what I meant by namespaces. If that means doing some internal trickery to act 
like module d comes from m_d, by all means do it. I don't mind modules 
sharing one scope - I haven't been bitten by that yet :)


> > In addition, having to do the did_import_ thing manually in the module
> > itself feels rather silly .. since it's obvious AAP _could_ set that
> > variable itself.
>
> I also suggested a solution for this: Only load the first module found
> in the list of "modules" directories, then load all recipes found in the
> "modules2" directories.  The first is to define the module, the second
> to tune a few things without making a copy of a module.

I don't see a need for this. If you :import d, then Id expect a file d.aap 
from some module directory to be read exactly once. Based on the current 
startup code, I'd expect to search in

- ~/.aap/startup/modules
- /usr/local/share/aap/startup/modules
- `the directory where the aap executable lives`/modules

in that order. If a user wants to tweak, say, the d module, the user can copy 
the whole module to ~/.aap/startup/modules and work with that. Most tuning 
should happen through variables, anyway, and you could always put tuning code 
in a separate module in ~/.aap/startup/modules, say you end up importing

	:import d
	:import d_tune

as long as all the modules share one scope for their variables, that would 
work.




> > Is there any situation you can think of where multiple module imports
> > would be useful?
>
> What do you mean by "multiple module imports"?  Importing the same
> module more than once?

Yes. I was wondering why you demand that the module writer put the line 
did_import_<modulename>=1 in the module, when AAP itself could do so as well. 
Do you expect module imports to fail (because of missing tools?) and want to 
have a way of reporting errors?


-- 
pub  1024D/FEA2A3FE 2002-06-18 Adriaan de Groot <[email protected]>
            If the door is ajar, can we fill it with door-jamb?



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf