ummm. . .yes, I specifically remember removing that for a reason, but for the life of me can't remember why. Perhaps I just wasn't thinking straight.

Good catch, I'd say let's add it back in as it will make the rest of the attribute tag processing a little simpler.

The only reason why we wouldn't want to modify the underlying ComponentAttribute would be if we want to support the case where:

1) type is calculated
2) no valid definition is found matching the name
3) type is set to string
4) definition is added to the container
5) tag is now in an invalid state as a recalculation would result in a type of 'definition'

or the opposite where a definition is removed, but we currently don't support removing definitions.

On the other hand, the benefit of setting the type after calculation is that it saves us a couple of nano-seconds because we don't have to recalculate the next time around (which is basically a couple of equals operations and a lookup in a map).

I could go either way. . .

David






Antonio Petrelli wrote:
Hi list, and especially David (H. DeWolf)
I noticed that you renamed AttributeTag.preprocessAttribute into "calculateType", and you removed all the logic that "fixed" the attribute object itself.
Is this "fixing" code moved anywhere, or is it been removed completely?

TIA
Antonio

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to