> Maybe the problem here is in thinking of devices in terms of an
inheritance
> hierarchy?
I'd say. More "HAS-A" relations, and fewer "IS-A-KIND-OF"
relations, makes more sense. I don't think I've seen any two
multiple-inheritance object models that did things the same way.
This approach also neatly partitions expertise. People who know
sound format deviations might not know browser foibles very well.
I still think some inheritance is good, chiefly for describing
how things go wrong.
> An alternate way would be to compose the descriptions of a number of
> different but related entities:
>
> <provider name="DoCoMo">
> yadda yadda
> </provider>
>
> <maker name="NEC">
> yadda yadda
> </maker>
>
> <device name="N503i"
> maker="NEC"
> provider="DoCoMo">
> ...
> </device>
> It might be appropriate to have devices belonging to device families, and
> then have the device family be able to specify (by name, or directly
inline)
> what the generic or default device should be for that family. This would
> make it relatively straightforward to provide fallback behaviors.
Ideally only one level of fallback. Inheritance should be shallow,
and unless there are major factoring advantages, isn't worth
the hassle.
> A lot of this stuff is actually in the CCPP spec, although I think that
> maybe (definitely?) it's more complicated than it needs to be.
> Something simple would be a better way to start, I think.
CCPP is from WAP, but hey, HTML was carved away from
a cumbersome SGML, and internet protocols made off with
a workable subset of ASN.1, otherwise avoiding most of
the execrable mess of OSI. Steal, steal, simplify.
[snip]
-michael turner
leap@gol.com
Received on Wed Feb 27 09:34:36 2002