On 10/2/06, Peter Reilly <[EMAIL PROTECTED]> wrote:
> >That would be *fantastic* Peter!!!
It would be nice to have. I have no
code but suspect that IH would hit new Complexity Limits.
Are you refering to a particular code metric? or saying this in general?
I personally think IH could be slimed down but extracting one or two
utility classes out of it, and that adding mixins, while undoubtly
adding some complexity, should be manageable.
> >Overlap in attr/elem between the main type and the mixins
> >would be silently ignored (maybe a warning a warn or debug
> >level only), the main type taking precedence;
Hard to know what is the best approach -whine or ignore?
As stated, I'm more for ignore, with a little whine at DEBUG level.
> You could also pass the value to both: the task and the mixin.
Mmm.. I do not think so - too much scope for bugs.
I don't like that either.
public class MyMixin /* extends PC/some baseclass? */ {
PC I think, to get location,and loging - just Object should work as well.
Yes, ideally any object could be used, but I have no problem with
forcing Mixins to be at least ProjectComponents. This may indeed
simplify implementation and would likely improve error handling. Once
(and if) PC-based mixins are out-in-the-wild and succesful, we could
revisit the restriction to be a PC, if necessary.
> <mytask foo="bar"/>
> --> MyTask.foo = "bar"
> --> MyTask.mixin.foo = "bar"
I'm not fond of this idea. Somebody doing MyTask.setFoo("baz")
programmatically will wonder why somehow the behavior of MyTask is
influenced by a "bar" somewhere, despite the setFoo("baz"). Violates
the principle of least surprise IMHO.
> Another possibility would be setting the back reference automatically
> public class MyMixin {
> Task caller;
> public void setTask(Task c) { caller=c; }
> }
I view mixins are reusable bits of code to be used by tasks/types, and
I'm not sure I want the mixin to be aware of its container at all. In
any case, a mixin that wants to know about its container can always
define its own ad-hoc documented protocol, but defining a setTask-like
method, and documenting that the container should call it. Let's keep
IH as simple as possible regarding mixins IMHO.
I would rather have annotations, [...] but that will not happen, so
void antMixin(RegexParams ..)
will have to do for the moment.
Regarding the name, what about composeMixin(Type t)?
I would like to emphasis mixins should be used for composition.
Note that antMixin will always be called, even if the no attributes or
nested elements are set
That's fine. Better that than null-checks everywhere. People that will
use mixin probably just like me used pure composition already, with
the trouble of having to expose all the set/add methods of the
composed types, so it's basically the same.
alternatively other naming convenetions could be used:
private RegexParams antMixinRegexParams;
Since we don't have antAttributeFoo, or antElementBar, lets not go there.
RegexParams getAntMixinXXX()
(where XXX is ignored by IH, but can ge used to have multiple mixins).
I prefer the semantic of antMixin(Type t), which allowed polymorphic
behavior, and already supports multiple mixin types thanks to method
overloading.
Object[] getAntMixins()
Again that would prevent polymorphism, and is less Ant-ish.
--DD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
