> Oppossum is a compromise, it eliminates the need for explicit typing > constructs (type names, characters, etc) for readability, but it looses > a bit of flexibility in doing so. > > I think what Oskar and I had in mind is that there would be very few > actual types, String, integer, float, boolean, maybe one or two more. > > Besides, I personally think things like date ought to be represented as > long quantites such as seconds since the epoch, which facilitate very easy > comparison and fits into a base type.
That's the best way to represent them in memory of course, but as text, dates are common enough a thing to treat specially for readability, and goo formats (like "2000-05-15 13:53:05") are directly comparable with simple string-compare. If we decide to weakly type fields, this format or something like it would be fine, although I actually think explicit characters would be simpler (if a bit less readable). Either one adds another half chapter to the spec and doesn't add even one capability, but if it there's really that much code that wants types, I can live with it, as long as it is clear in the spec that ALL semantic meaning of every field exists totally and exclusively in its name, and these encoding types are extra information for code convenience only. -- Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lee/> "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
