Well, here's my take on the data inheritance thing: in most cases,
why bother?
A lot of this stuff is just whacking in data from spec sheets. Do
I really want to sit down and figure out what my F503i shares in
common with other 503i models, and which particular thing it should
inherit from, and so on? Or do I just want to look at the spec.
sheet and type in "screen width = 130 pixels" and "screen height
= 160 pixels"? The latter is faster to create, and also easier to
read and debug (because I don't have to go looking in another place
to see what's being inherited).
There might be certain situations where inheritance could help.
Say we have eighteen different pieces of data for a sound chip,
and we know that all phones that use that sound chip work exactly
the same in that respect (this is a big supposition). In that case
it might be useful to say, "sound chip = yamaha foo". But I'd want
to verify that that's actually the case before going to the effort
of doing that work. If and when we start to see large chunks of
common data, we can refactor to consolidate that.
Keep in mind that inheritence is useful because it works *both*
ways; you can change the behaviour of all your children by changing
the parent. But it doesn't seem so likely to me that we'd ever want
to do that; why on earth would I ever want to change the screen
size of an entire group of phones?
As for Christian's thought about using a format easier to edit than
than XML: I'm open to that. If we're not getting an extra boost
from XML that makes up for the difficulty, why use it? In fact, we
might just as well do the initial implementation with Java-style
properties files, and move to XML only when we figure out how that
doesn't work for us.
cjs
--
Curt Sampson <cjs_at_cynic.net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
Received on Tue Feb 26 18:50:05 2002