[snip]
> >Then we would change Element.InitializeAttributes to get all members
> >that have a TaskElementAttribute and their return type. If the return
> >type derives from Element, follow the same rules we do for
> >BuildElementAttribute matches.
> >
> How is this different to what happens now in
> Element.InitializeAttributes ?? I'm not sure what you want to change
> here. The only addition I see is to handle the array case. Please
> explain what you mean bout the return type here. Do you just want to
> ensure that attributes are only placed on Element derived classes ?
>
The change I'm talking about is supporting the else case. Right now, if
you don't derive from Element, you don't get any more data. I'm
suggesting that we don't require this. If we want to require something,
make it an interface, not an abstract/base class.
Also, I think for the current code to work, you need to define both a
set and get on the property, as well as return an initialized object.
This sounds reasonable but should probably be documented somewhere. If
this is true, we should probably do a little more checking.
>
> >Else run the type though something like
> >InitializeAttributes(which takes the return type). (This will go on
> >recursively while there are TaskElementAttributes to process.)
> >
> >
> >Also, I think we may want to change the Task prefix into an NAnt one.
So
> >TaskAttributeAttribute becomes NAntAttributeAttribute.
> >
> Wel lets decide on a consistent naming scheme by all means. I'm not
sure
> NAntAttribute is the way to go. We're inside the Sourceforge.Nant
> namespace anyway, it seems to be needless duplication to say NAnt
again.
> Still if we can't find better names.
What about following the xml serialization standard and call them
XmlAttributeAttribute and XmlElementAttribute? We could even set them as
derived classes of the serialization ones.
Thoughts?
_______________________________________________
Nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
