Re: EAV (Re: Object-relational impedence)
Date: Sat, 29 Mar 2008 19:10:03 +0100
Message-ID: <1kikgag7cq3zi$.ufxkz5oaeff.dlg_at_40tude.net>
On Sat, 29 Mar 2008 15:37:13 GMT, Brian Selzer wrote:
> "Dmitry A. Kazakov" <mailbox_at_dmitry-kazakov.de> wrote in message
> news:e5lufueeu155.t1s8vlmxjhpt.dlg_at_40tude.net...
>> On Sat, 29 Mar 2008 04:47:01 GMT, Brian Selzer wrote:
>>
>>> There is a table for attributes that are common to all
>>> possible widgets, and a table for each set of attributes that are common
>>> not to all possible widgets, but rather to a subset of all possible widgets.
>>
>> It is interesting to see people reinventing the wheel (class). The set of
>> "all possible widgets having attributes T, U, V" is a class.
>
> That depends upon how you define what is a class. The set of all possible
> widgets having attributes T, U, V, such that T and U have the same sign is a
> different class. The set of all possible widgets having attributes T, U, V
> such that T and V have the same sign is also a different class. Under this
> definition, a widget may be a member of all three classes, right?
Is the sign of attributes itself an attribute, or it is a constraint put on them? But basically, yes classes can intersect.
... and the point is, the problems and choices you have been discussing is the good old OOA/D with relational representations as a vehicle.
>> But that is not my point. The problem with widgets hierarchy is that there >> are three axes of widget relations. You were discussing only one of them >> attributes, which is usually directly mapped to types. This is not that >> big deal. More difficult are other two: >> >> 2. Visual containment. Widgets can consist of / contain other widgets.
>
> If a widget consists of other widgets, then it must have attributes that are
> also widgets. If a widget contains other widgets, then it either has one
> attribute for each contained widget or an attribute that is a set of
> widgets. Visual containment can be defined in terms of attributes, so I
> don't understand why it is a problem.
(I am surprised that you did not mentioned a natively relational solution. I thought you would propose parent-child relation.) Anyway, an attribute-based model is very weak. It is like to have only record types but no arrays. There are lots of widgets which contain an unknown in advance number of other widgets. Another problem why your and the relational model I mentioned before would be problematic is handling all sorts of ordering, layout, alignment, size constraints put on contained widgets. In the traditional OO GUI design these constraints are a part of the container widget behavior. For example, GTK+ table widget arranges its children in columns, calculates its own size from the sizes of children (that goes recursively) etc. It would be extremely tedious to expose this stuff in terms of attributes for the poor user...
>> 3. Signal handing. Handlers of widget events are composed in a certain >> hierarchical way.
>
> You don't store widgets, you store snapshots of widgets. How one widget
> communicates with another has no bearing on how the snapshots of each are
> stored. So where is the problem?
I don't see your point. When you hit a mouse button, that should have some effect on the snapshots. Even if we ignored an application processing the event, there is a delivery to it and animation. For example, a button widget under the cursor gets down and up, while the sequence left_mouse_press, mouse_release is translated into button_click.
-- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.deReceived on Sat Mar 29 2008 - 19:10:03 CET