Re: FYI: 6/ Automake::Variable & Automake::VarDef

[Alexandre Duret-Lutz]

Hi Raja,

(BTW, is Raja your first name, or is it Harinath?  I'm confused
because you sign 'Hari'.)

>>> "Raja" == Raja R Harinath <address@hidden> writes:

[...]

 Raja> A few comments:

Great!  Thanks for doing that.

 Raja> [snip]
 >> Index: lib/Automake/Variable.pm
 Raja> [snip]
 >> +sub reset ()
 >> +{
 >> +  %_variable_dict = ();
 >> +  %_appendvar = ();
 >> +  @_var_order = ();
 >> +}

 Raja> I think this should reset %_hooks too.

Hmmm.  Right now we register hooks (or should I say "the hook"?)
once for all during Automake's startup.  Clearing %_hooks here
means we must register them again for each Makefile, although
they will not change.  I'm not convinced this is better, but I'm
not sure this is really what you suggest either.

[...]

 >> +C<$cond>: the DisjConditions in which C<$var> is being defined.
 Raja>             ^^^^^^^^^^^^^^

 Raja> ???  Isn't this the Automake::Condition.

Undoubtedly.

 Raja> [snip]
 >> +sub variable_defined ($;$)

 Raja> I think this belongs back to 'automake.in'.  That'd be the right
 Raja> place to encode the information about Automake::Rule, when you add it.

 >> +sub variable_assert ($$)
 >> +sub examine_variable ($)
 >> +sub require_variables ($$$@)
 >> +sub require_variables_for_variable ($$@)
 >> +sub variable_value ($)
 >> +sub variable_value_as_list($$;$)

 Raja> I think these belong to automake.in, too.  They don't
 Raja> seem to fit the mold.  It's a tossup, but I think these
 Raja> are more peculiar to the way Automake uses the variables,
 Raja> than about implementing the variables.  That's not really
 Raja> a distinction :-), but ...

I think at some point I moved one of these function to Variable,
and it pulled all the others :) But I'm not satisfied with
having these there either.  Some of them, like variable_value
and variable_value_as_list, could easily be rewritten and used
as methods.  The other probably do not belong to Variable.pm
because they can work on unexisting variables.

While I wrote Variable.pm I had a plan to convert these into
methods.  The problem is that these functions can work on
unexisting variables, but you can't call a method without a
Variable instance.  The idea was to add a new lookup operator:
`mvar' (for `maybe var') that either return an existing
variable, or create a new instance *without* registering to
%_variable_dict.  So you actually can call methods on a kind of
ghostly variable.  That sounds a bit clumsy.

How about moving these to a separate package (Automake::VarAux?
Automake::VarFuncs?  Automake::VarSupport? Automake::VarMisc?)
that would be a sort of layer on top of Automake::Variable (and
Automake::Rule once it's there).  I'm not against moving back to
automake.in, but I'd like to consider other possibilities.  As
we move more and more things out of automake.in (which I think
is a good thing), these functions will be needed outside.

[...]

 >> +  $var = ref ($var) ? $var : rvar ($var);

 Raja> Since this is used only as a method, this seems redundant.  Document
 Raja> this as $self->output(address@hidden) instead?

Agreed.

Thank you!
-- 
Alexandre Duret-Lutz