Re: Language module support added

Adriaan de Groot wrote:

> 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 :)

Yes, the idea is that the module file is called "d.aap", you use
":import d" and this ends up being the "m_d" scope.

If there is an additional "modules2/d.aap" recipe it is read into the
same scope.

As a result we have these type of scope names:

	_foo	built-in scopes (_no, _recipe, etc.)
	s_foo	user scopes (recommended name only)
	m_foo	foo module (m_libtool, m_java, etc.)

> > > 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.

The problem with most users is that they only want to change a minor
thing, e.g., the name of a compiler.  Making a copy of the module then
has the disadvantage that every time an updated version of the module is
available the copy has to be made again.  Or the updated module isn't
noticed at all.

Importing a "d_tune" module can only be done when the person who writes
the recipe knows that this module is needed.  This won't work for the
situation you are using a downloaded recipe and your local system
requires "d" files to be handled a little bit differently.

It's my experience with Vim plugins that tells me that this kind of
tuning is necessary in some situations.  Anyway, if you don't need the
"modules2" directory you can just ignore it.

> > > 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?

The reason for that variable was to distinguish between a module recipe
that does the main defining of actions etc. and a recipe that only adds
a few things.  With the separation in "modules" and "modules2" this is
no longer required, thus it can be left out.

-- 
Bumper sticker: Honk if you love peace and quiet.

 /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net   \\\
///          Creator of Vim - Vi IMproved -- http://www.Vim.org          \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///


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