Re: EAV (Re: Object-relational impedence)

"Dmitry A. Kazakov" <mailbox_at_dmitry-kazakov.de> wrote in message news: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...
>

It's a simple matter to flatten out nested relations. Also, modeling a 1:0..n relationship is child's play. Ordering, layout, alignment, size can all be represented by exposing attributes and defining functions and relations. If the size of a widget depends upon the size of its children then it must be the result of an aggregate function. It's generally bad practice to record the results of an aggregate, since the value can be arrived at by simply computing the aggregate. Any change that might affect the aggregate result would then necessarily require a recomputation of the stored aggregate value.

>>> 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.

When you hit a mouse button, the state /may/ change. When the state changes, another snapshot can be taken to replace one that had already been recorded. Not every mouse click results in a change of state. For example, someone hits the "Clear" button on a screeen that has already been cleared, or someone double-clicks the "Clear" button, and the double-click is interpreted as two single-clicks. When there is no change of state, there is no need to record a change of state. Bottom line: the fact that a left-mouse-press, left-mouse-release translates into a button_click is irrelevant. What has delivery and animation to do with tracking widget state?

>
> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de
Received on Sat Mar 29 2008 - 19:54:11 CET