Re: Objects and Relations
Date: 23 Feb 2007 22:16:40 -0800
On Feb 24, 12:12 pm, "Marshall" <marshall.spi..._at_gmail.com> wrote:
> On Feb 23, 6:40 pm, "David BL" <davi..._at_iinet.net.au> wrote:
> > You did not realise my point? I'm talking about representing these
> > things and processing these things, and not merely stating facts
> > *about* these things. My whole point has been that RM is perfect for
> > the latter but not so good for the former. If you agree with that
> > then please say so.
> I don't, and as near as I can tell no one else here does either.
> > If you think RM is suitable for scenegraphs I would be particularly
> > interested.
> That is a strange way to think about it. On the one hand you have
> a collection type and on the other hand you have application level
> constructs. Let's invert it:
> If you think hashtables are suitable for payroll I would
> be particularly interested.
> Doesn't make much sense.
> (Note that this is *structurally* similar to what you wrote,
> but not semantically similar.)
I'm not interested in metaphorical argument.
I'm aware of half a dozen scenegraph frameworks and none use the relational approach. Often scenegraph nodes are Java or C++ objects and the drawing of the scene, hit testing and other functions tend to emphasise the OO approach - complete with a class hierarchy for the node classes. Often scenegraph nodes exhibit behavior. For example manipulators that allow for the scene to be edited. However, at another level the scenegraph can be regarded as just data that needs to persist.
I'm curious to know whether RM would provide any advantages in this domain. Perhaps you are aware of some research.
> If you want to compare apples to apples, the thing to
> compare relations with is other data structures.
> Compare relations with C++ objects. Or with any
> of various things you'd find in the STL. Compare
> them in terms of what operations you'd like to perform,
> as well as what you'd like to model.
That's clear and I agree with that. I don't believe I've implied otherwise.
> I did this a while back for two Java stalwarts, Hashtable
> and ArrayList. It was immediately clear that none of
> the methods on those classes were worthy of making
> into an abstraction; they were all trivially accomplished
> with RA operations.
Received on Sat Feb 24 2007 - 07:16:40 CET