ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject RE: if and unless attributes for all Tasks
Date Wed, 16 May 2001 13:41:27 GMT
> From: Conor MacNeill [mailto:conor@cortexebusiness.com.au]
>
> > From: Peter Donald [mailto:donaldp@apache.org]
> >
> > if you mean the ant-calls for src and bianry distributions
> then I agree -
> > UGLY ;) Though it is better than any alternative I could
> think of - you ?
>
> True enough. I think we are using these antcalls primarily as
> a way to get
> around the immutable properties in Ant - right? So, I see
> these resulting
> from another Ant "feature". We solve that problem using the
> tools at hand -
> antcall.
>

As one of the most ardient defenders of the "feature" (aka: inmutable
properties) I feel compelled to speek out.

Properties define the context of execution for targets. In particular
properties are defined in function of other properties (i.e.
value="${otherProp}.blah" ). If properties where mutable, the only way to
know what is the actual value of a property is to trace the sequential
execution (which changes depending on the target called, or the execution
strategy of the engine, or if we allow parallelism, or ...) and find out
exactly the order in which properties get their values and how they change.
This is imperative programming at its worst. Why? Because we don't even have
a nice "top-down", "follow the calls" way to read a buildfile. The only
thing specified there is a list of dependencies, add a new dependency and
the whole execution order may change drastically. Inmutability means that to
certain extend ANT guarantees an stable environment for targets to execute
independent of order.

It is not perfect, for example, we shouldn't allow the expansion of
"${prop}" if "prop" is not defined. We should fail the build because there
is definetly a missing dependency or we should have use if/unless to protect
it. (yes if/unless) 8-)

Now back to <antcall>, the point of <antcall> is that it provides a new
execution environment based on the new values provided in its parameters.
These is a new stable view in which the targets can proceed. This is
declarative and I see no fault with it.
As I have hinted before, however, I have some problems with the way the
current <ant*> in general works. I think the current inheritance rules
violate this principle of an stable environment. Each execution should be
able to recompute the values of their internal properties based on the
parameters of the call, we should not be stuck with the values of properties
in the caller which may have meant something completely different, as oppose
to parameters which were passed explicitly. But, this is for a separate
thread.

> It is the same with if and unless. Those are the tools we
> have provided and
> a lot of problems can be solved that way, but sometimes it
> forces the build
> writer into unnatural contortions. The end result is that the
> build file is
> complex and the intent of the build file's author is lost.
> Compare Jose
> Alberto's target based example against the original in the
> patch. It works
> in the current Ant, but is it better?
>

Good question, but we need to ask also what do we mean by better/worst.
How understandable build files will be depend on our choices. If I write
targets where every <task> has a different if/unless condition, what does
that tell me about the readability of the build file. It looks like
spaggetti code to me. I think the granularity is too low. By having
if/unless at <target> level, you still can write spaggetti code, but it will
make you think: "Do I really need to do it this way?" And that is what makes
code understandable and maintainable, you have to stop and think.

> I like this discussion since we should always be ready to
> question whether
> there is a better way of doing things. That is why I'd like
> to hear from Jon
> on his thoughts for a better way of doing the uptodate
> checks. uptodate is a
> direct result of the if/unless mechanisms we currently have.
> Is there a
> better way?
>

Yeap, lets hear it.

Jose Alberto


Mime
View raw message