[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [buckminster-dev] Action properties [WAS Action output?]
|
I think that an action should have two types of properties. The ones that
it has full control over and the ones that it can inherit.
When an action executes, the inherited properties can be overridden by
properties passed on the command line *and* by properties set by actions
that have executed earlier in the chain.
A fixed and fully controlled property can still be subject to inheritance
since we use the ${xxx} substitution pattern.
'Inherited' properties is great and something we could/should have, I agree.
Actually, I think inherited is the wrong word, it's more 'arguments' to an
action. We should talk more of actual definition of how it should work. For
example, when thinking about your example below, I'm worried that it opens
up another can of worms, as in when and in what order properties are
resolved in order for them to be resolvable like that at the proper time.
That said, I still don't think 'inherited' properties should actually be
involved in the problem I wish to be solved, I'll argue below.
Hmm, sorry. I missed that A was dependent on B. So OK, A would need to
redefine coolselector in this case, before calling B. Tricky. That implies
that you must be able to set properties on the prerequisite as such.
<action name="A" ...>
<prerequisites>
<local name="B">
<property name="coolselector" value="${becoolselector}"/>
</local>
</prerequisites>
...
</action>
You can now do:
perform A -Dcoolselector=cool_a_stuff -Dbecoolselector=cool_b_stuff
Small note: the local should be an external, right? And, this is important:
I actually I screwed up my example a bit - A was 'myself' which I *did* have
control over - I was actually meaning that *C* had a coolselector that
should get cool_c_stuff...sorry. Though the problem might actually be
technically solvable this way anyhow. Maybe my error about confusing A and C
changes your picture, but I'll just make the rest of the argument anyway....
While this *technically* solves the problem, I don't really care for it
(except for the general usefulness of being able to pass props to other
actions). One reason is that it is just a workaround for a *fundamental*
problem we have created in the first place by *not* providing property
isolation. Another reason is that it places the burden on 'me' (A) to fix
issues between B and C. Or any other action ever that has the same
dependency to B (and then C). Finally, this assumes that I'm fully aware of
the problem with this property, the consequences and the proper solution
(*workaround*).
That all seems silly to me.
And further, avoiding technical solutions for a second, just think about
'the philosophy'. We spend a lot of time working with making sure components
otherwise are isolated from each other, we deal with namespaces and all the
other ways to *help* users avoid making mistakes. True, we can't handle all
cases, but in this case I have yet to see a good argument as to why we
should suddenly throw that mindset to the winds. You say 'KISS', and that
the use-case is 'uncommon'. If we would have stayed with KISS, there's a lot
of things we could do much, much simpler (and much more error-prone).
There's another saying: 'keep it as simple as possible, but no simpler' -
i.e. if we have to do a bit more (and not much in my opinion) to avoid what
I believe is a very real(istic) problem, then that's better for everyone in
the end. Even if a commandline get's a bit icky...
ken1
