> The issue is when you attempt to copy the data from one FieldSet to another. > For example, all the fields in the subset "storable" are stored in the > DataProperties with the data (DataProperties does not implement fieldset right > now, but it should).
I looked at the code--DataProperties is fine, it's FieldSet that goes a lot further than it has to. There's really no reason for it to know about data types, and there isn't any code that I can find that needs this. There are a few lines that use it, but they'd actually be simpler without. FieldSet should keep a collection of names/strings, nothing else. It should also have convenience functions to get/set numbers, but these are just conversion wrappers that store the field as a string like all others. That much I'm sure about. FieldSet is far too complex and violates the spec as written. The following I'm not so sure about and would appreciate your feedback: as you noticed, dotted fields require a method that returns a collection of fields matching the name given rather than a single one, because multiple subclasses are possible (another reason to avoid data types since sibling subclasses of the name passed may be different subtypes requiring heterogenous return collection). I think I've specked rules about limiting subclassing rigorously enough that it would nonetheless be safe to also include a convenience method getField(name) that returns the one matching field value and throws an exception if there is more than one. -- Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lcrocker.html> "All inventions or works of authorship original to me, herein and past, are placed irrevocably in the public domain, and may be used or modified for any purpose, without permission, attribution, or notification."--LDC _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
