Re: EAV (Re: Object-relational impedence)
Date: Sun, 30 Mar 2008 10:45:43 +0200
Message-ID: <9b4f6jjfc7ms.1trfqsj83x2m3$.dlg_at_40tude.net>
On Sat, 29 Mar 2008 17:03:53 -0700 (PDT), topmind wrote:
>> 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.
>
> With the existing implementations of RDBMS, I reluctantly have to
> agree. However, in an ideal world, Dynamic Relational would exist so
> that we wouldn't need to go to the dark side (OOP).
The question is not how, but what.
Dynamic vs. static is a secondary issue. An inability to check your design against some errors is not an advantage, when taken alone. You should first show what are you doing. Then you prove that it is necessary to go this way and that it is indeed statically uncheckable. Only then anybody would buy it dynamic.
>> 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.
>
> I'd prefer references rather than containment. This would allow say an
> embedded panel to but "popped out" in a dedicated screen if the user
> wanted. And have a form be windowed in another in one tab, but by
> itself in another.
I meant visual appearance. You can implement it as you with, but an edit entry is visually contained by the dialog. That is a requirement.
> Besides, all we need is a "parentWidgetID" to have a basic hierarchy
> with tables.
That does not work as I explained in another post.
>> 3. Signal handing. Handlers of widget events are composed in a certain >> hierarchical way.
>
> I don't see why this has to be the case. We may want a form-level
> handler to take precedence over a widget-specific handler in some
> cases. The priority should be developer-alterable at run-time. Tables
> would be much better at tracking all these priorities than a tree.
Priorities is another word for hierarchy.
> The biggest drawback of an OOP GUI system is that it is difficult to
> make a cross-language OO framework. Each OOP language has such
> different rules about inheritance and encapsulation such that building
> a sharable framework is sticky. Most successful cross-language
> frameworks tend to be declarative, and OOP is anti-declarative for the
> most part.
Ah, and that is different with SQL? Come on, SQL is incompatible with itself. Now imagine, there were more than just one relational language in use?
-- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.deReceived on Sun Mar 30 2008 - 10:45:43 CEST