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]