Re: Object-relational impedence

From: Leslie Sanford <jabberdabber_at_bitemehotmail.com>
Date: Mon, 3 Mar 2008 18:47:45 -0600
Message-ID: <47cc9c54$0$1091$4c368faf_at_roadrunner.com>


"JOG" wrote:
>
> This reminds me of a serious 'click' moment I had with data
> structures. A long time ago, in a galaxy far far away, I once sat
> blindly reinventing my own network model, with identifiers, pointers,
> types, and all the fun of the fair. As an OO programmer it was the
> only mindset I had. Then I considered encoding data similar to the
> classic example of:
>
> * Aristotle is a man
> * All men are mortal
> * |= Aristotle is mortal
>
> Well, /clearly/ what I was dealing with here was a generic entity
> class, of which Man was a subclass, and Aristotle an instance.
> Something like:
>
> class Entity
> {
> boolean mortal;
> string name;
> Entity(_name, _mortal) : name(_name), mortal(_mortal);
> };
>
> class Man : public Entity
> {
> date bday;
> Man(_name, _mortal) : Entity(_name, _mortal), bday(_bday);
> };
>
>
> But, as I extended the example, the structures got more convoluted,
> and the result more and more of a mess. Finally something clicked. It
> wasn't about types, objects or inheritance, it was about /inference/,
> and what I actually had was:
>
> Name(x, Aristotle) -> Species(x, Man)
> Species(x, Man) -> Mortality(x, Mortal)
> |= Name(x, Aristotle) -> Mortalilty(x, Mortal)
>
> No types or reification in sight. Instead I had two groups of
> statements:
> People = {Name, Species, Bday}
> Entities = {Species, Mortality}
>
> A join of the two statements gave me the inference I required: {Name,
> Mortality}. All of a sudden it seemed simple. So some questions:
>
> 1) So why not treat all 'inheritance' in this way?
> 2) Could one extend to include 'behaviour' as well?
> 3) And is this a crazy thing to suggest in a cross post to an OO
> group?

I'm jumping in realizing that I may be revealing a bit of ignorance here, so bear with me.

If I need to send a message to all persons who are mortal, I could join People and Entities together by species and where Mortality is true?

Once I've performed the join, I then dispatch a message to the resulting group: "GetAnnualCheckUp()" or something?

In the application I'm currently writing, I have a large list of parameters. These parameters share some values such as Name and Label. However, there are different types of parameters such as those that represent a boolean state ("on/off"), a selection of choices, e.g. "Sine", "Sawtooth", "Square", etc., and other types. My current approach is traditional OO, and that's to have a hierarchy of Parameter classes. I can then keep a list of heterogeneous parameters and treat them polymorphically. For example:

params[AmplitudeId] = new FloatParameter("Amplitude", "dB", 0.0f, 1.0f); params[WaveId] = new SelectionParameter("Wave", "Type", WaveNames);

// Set a parameter value. All raw parameter values are in the range
// of [0, 1]. Each parameter class knows how to transform raw parameter
// values in an appropriate way.

params[parameterId].SetValue(value);

And all works well.

I'm trying to wrap my head around how I would approach this problem using what you've described above. I could have a table representing attributes common to all parameters. Then tables representing attributes specific to one parameter type or another. I could relate the tables via foreign keys? When I need to dispatch parameter changes, I could join the appropriate tables and change the appropriate values?

I'm open to new ways of approaching things, but the mechanism to implement all of this needs to be fast, in my case. Parameter changes can come in at hundreds of times a second. Received on Tue Mar 04 2008 - 01:47:45 CET

Original text of this message