Re: EAV (Re: Object-relational impedence)

Dmitry A. Kazakov wrote:
> On Sat, 29 Mar 2008 17:03:53 -0700 (PDT), topmind wrote:
>
> > Dmitry A. Kazakov 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.

Being statically checkable is usually overrated by the "compile fanboys". Anyhow, I don't want to get into an compiler-vs-interpreter fight here. If you like static checking, so be it. Nothing will satisfy everybody.

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

I missed it. But I have used "parent ID" to represent trees in tables (unrelated to GUI's) and it DOES work. Don't tell me it doesn't.

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

Or an ordered list. Anyhow, the event priorities may not and do not always match the physical containment hierarchies. Thus, traditional OO hierarchies are insufficient.

>
> So, you want to leave it to the developer, oh my. Could you give us a short
> sketch of how, for instance D&D events can be handled this way? You press a
> mouse button at something, then track the mouse motion, and finally process
> mouse button release... Good luck.

I've never really played D&D. Damn, I guess they'll revoke my Nerd Card for admitting that. Note that there would be default priorities inserted/assumed by the GUI IDE such that each individual one does not need hand tuning, only the odder ones.

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

SQL is one of the best cross-language integration tools there has ever been, even WITH its flaws. Only HTTP/HTML can touch it.

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

-T- Received on Sun Mar 30 2008 - 12:21:59 CEST