Prev: event handling issues in presentation model
Next: Mixing OO and DB
From: David Cressey on 29 Mar 2008 09:14

"Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message
news:e5lufueeu155.t1s8vlmxjhpt.dlg(a)40tude.net...


> It is interesting to see people reinventing the wheel (class). The set of
> "all possible widgets having attributes T, U, V" is a class.

The pattern of "generalization-specialization" predates both the relational
data model and the object oriented paradigm. Neither one of them really
derived that pattern from the other. There is undoubtedly a common
intellectual ancestor, but you might have to go back centuries to find it.



From: Dmitry A. Kazakov on 29 Mar 2008 09:58
On Sat, 29 Mar 2008 13:14:49 GMT, David Cressey wrote:

> "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message
> news:e5lufueeu155.t1s8vlmxjhpt.dlg(a)40tude.net...
>
>> It is interesting to see people reinventing the wheel (class). The set of
>> "all possible widgets having attributes T, U, V" is a class.
>
> The pattern of "generalization-specialization" predates both the relational
> data model and the object oriented paradigm. Neither one of them really
> derived that pattern from the other. There is undoubtedly a common
> intellectual ancestor, but you might have to go back centuries to find it.

Yes. That by the way implies that neither is a paradigm in that respect.
"Class" is just an implementation of the pattern, i.e.

1. how could I describe a set of similar types? (Similarity is defined in
terms of behavior.)

2. can I have make its closure another type? (This gives polymorphism)

The same steps would apply to relations. So generic relational programming
(if that thing will ever happen) would deal with classes of relations
represented by relations.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Roy Hann on 29 Mar 2008 10:11
"topmind" <topmind(a)technologist.com> wrote in message
news:79cae24d-bca7-47e5-94f6-7bb5bfa508f1(a)s8g2000prg.googlegroups.com...
>
> I never liked table-happy designs,

You prefer code-happy designs?!

I've heard enough. Plonk.

Roy


From: Brian Selzer on 29 Mar 2008 11:37

"Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message
news:e5lufueeu155.t1s8vlmxjhpt.dlg(a)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?

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

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

> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de


From: Dmitry A. Kazakov on 29 Mar 2008 14:10
On Sat, 29 Mar 2008 15:37:13 GMT, Brian Selzer wrote:

> "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message
> news:e5lufueeu155.t1s8vlmxjhpt.dlg(a)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.de
 |  Next  |  Last
Pages: 1 2 3 4
Prev: event handling issues in presentation model
Next: Mixing OO and DB