[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[buckminster-dev] "obtained from" revisited
|
Hi,
I'm having second thoughts about the suggested dependency prerequisite
mechanism, A.K.A. "obtained from". It implies that the component where
the dependency is expressed knows how the dependency is resolved.
Without that knowledge, we write:
Example 1.
<cspec name="A">
<dependencies>
<dependency name="B"/>
</dependencies>
</cspec>
which is clean. Using the "obtained from" we must instead write:
Example 2.
<cspec name="A">
<dependencies>
<dependency name="B.generator"/>
<dependency name="B">
<obtainedFrom component="B.generator" attribute="generate"/>
</dependency>
</dependencies>
</cspec>
Using the first example, how did B come into existence? While we
certainly solve that particular problem in example #2 we also clobber
component A with knowledge that it should not have.
I'm beginning to lean towards a solution where this must have been taken
care of within the scope of the resolution /before/ we reach component
"A". I.e. in order to express something like this, we need some kind of
'scope' where we add knowledge of what components that are expected to
be generated within that scope and by whom.
Here's one suggestion on how to solve this. We add a new section in the
cspec. Let's call it 'generators'. We could then express what we want
using Example #1 above in combination with this:
Example: 3,
<cspec name="X">
<generators>
<generator
component="B.generator"
attribute="generate"
generates="B"/>
</generators>
<dependencies>
<dependency name="A"/>
</dependencies>
</cspec>
When resolving component 'X', Buckminster would find the generator
declaration and hence, would not try to resolve B. Instead a special
GeneratorNode would be inserted into the BOM. The generators are then
called during the materialization process.
Personally, I think this is a much cleaner solution. It would supplant
both the 'obtained from' concept and the special 'bind.entry.point'
attribute. The 'prebind' would remain unaffected since thats a way to
complement an existing component, not create a new one.
Thoughts?
Kind Regards,
Thomas Hallgren