As I said, I want the code to be independant of how values are encoded in the protocol. As long as I cannot tell at read time whether it is a numeric, boolean, or string value I will have to use the current complicated FieldSet using the interface. If I could tell at read time, then I could make the FieldSet much easier, since it would have to be transport dependent.
I don't see the thing with the "sibling subclasses" either. A FieldSet is a set of fields, these fields can contain among other things other sets. The fact that the current transport represents this using a dot method is not important. And I don't believe there is a need for a method that searches for a field in all the subsets with a certain name. I can't see any use for such a method. On Wed, 10 May 2000, Lee Daniel Crocker wrote: > > 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 -- Oskar Sandberg md98-osa at nada.kth.se #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/) _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
