too much OOP ?
in [OOP]
|
Prev: Should class code access private members or public wrappers for those private members?
Next: Should class code access private members or public wrappers forthose private members?
From: frebe on 6 Jan 2008 08:19 > > SQL is a perfect language for reading and writing the GUI data. Lets > > say you have a combo box. Just write a select statement returning the > > data in the combo. > > Sure, MVC works nicely for combo boxes and a relational model (but not SQL > of course) in place of "M" is perfect there. It becomes a lot clumsier with > tree view widgets, as expected. Connect by, maybe. > But you forgot about "V" and "C", that > widgets are natively hierarchical, as well as signal handling there. Hierachical, really? How do all business applications out there using SQL databases, model company organizations? What makes you think that the relational model can't model hierachies? > > Also the GUI layout could easily be described using relations, > > I would really enjoy a serious attempt to build a relational widget > library. The most difficult problems will be composition of signal handlers > and renderers in a flat relational way. The former are hierarchical, the > later are spatial. Let's draw a line update pixel set color=black where 2*x+y=100 and x between 100 and 200 Any tuning complete language would be capable of building widgets, given that the appropriate functions for accessing the hardware, exists. A relational language is like any other language, except is has build-in support for relational algebra. It can have functions (user-defined or native), control structures and even classes. As a matter of fact, a relational language may very well use classes to define new domains and operators for these domains. The problem starts when people are using classes as data structures. //frebe
From: frebe on 6 Jan 2008 08:35 > >>>> 1. For most of requests an RA description is close to optimal; > > >>> It doesn't need to be optimal, it just needs to be a practical way of > >>> getting at the data now. > > >> A difference between O(log n) and O(n) might quickly become impractical. > > > Who said that it need to be O(n) because you use RA? > > I do. When you are wrong. Any junior programmer know how to write SQL queries and index that perform O(log n). > > RA has nothing to do with the physical layer. > > The view limits possible implementations. View is a model, when the model > is wrong, there is no implementation possible. When the model is inherently > inefficient so will be the implementation. Who proved that the model is inherently ineffeicient in the given scenario? > If you believe that RA is the > best model for everything, then try to use it for integer arithmetic. select 1+1 from dual The relational model is without doubt more powerful than the two preceding models: The hieracial and the netwok models. In your agumentation, you are igonoring the fact that the relational model is a logical model. Other data structures are used in the physical layer (implementation). Current SQL database realy heavily on B-trees in the physical layer. This has been proven to be very practical in most scenarios for "business applications", and less practical in other scenarios like GIS. But other index types may very well be used when suitable. The fact that this isn't the case with many mainstream databases, is a limitation in availible products, not in the relational model. //frebe
From: Dmitry A. Kazakov on 6 Jan 2008 09:05 On Sun, 6 Jan 2008 05:19:04 -0800 (PST), frebe wrote: > What makes you think that the relational model can't model hierachies? Because it has disastrous O(m x log n) for path navigation. Hierarchies are more complex than flat relations. This is the price to pay for efficiency. It makes all things more difficult, with a single advantage, it works. >>> Also the GUI layout could easily be described using relations, >> >> I would really enjoy a serious attempt to build a relational widget >> library. The most difficult problems will be composition of signal handlers >> and renderers in a flat relational way. The former are hierarchical, the >> later are spatial. > > Let's draw a line > > update pixel set color=black > where 2*x+y=100 and x between 100 and 200 [ update pixel set color=black where x, y in glyph-A of family Arial of Italic of Pitch ... (:-)) ] This has O(n^2) complexity, already in such a trivial case. Analytic and algebraic geometry aren't good rendering. Further the question was about composition. The performance of modern graphic accelerators is all about composition. They don't render invisible things, they don't render same things twice. This sort of optimization is what you loose first with this naive approach. You need not to answer today. Write a working library first... (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on 6 Jan 2008 09:21 On Sun, 6 Jan 2008 05:35:45 -0800 (PST), frebe wrote: > Who proved that the model is inherently ineffeicient in the given > scenario? Proof: Let S be an unordered set. q.e.d. >> If you believe that RA is the >> best model for everything, then try to use it for integer arithmetic. > > select 1+1 from dual I don't see how this implements "+". A relational implementation of a+1 could be: table Sequence_Relation is (Predecessor : unique; Successor); select Successor from Sequence_Relation where Predecessor = a; Now do a+b, a*b, a!... Or maybe you want to try you luck with: table Natural is (First_Digit; Second_Digit; Third_Digit; ...); (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: frebe on 6 Jan 2008 09:48
> On Sun, 6 Jan 2008 05:19:04 -0800 (PST), frebe wrote: > > What makes you think that the relational model can't model hierachies? > > Because it has disastrous O(m x log n) for path navigation. Hierarchies > are more complex than flat relations. Now you are making assumptions about the physical layer that are not necessarly true. A SQL database implementation may very well using pointers between records. > > update pixel set color=black > > where 2*x+y=100 and x between 100 and 200 > > [ update pixel set color=black > where x, y in glyph-A of family Arial of Italic of Pitch ... (:-)) ] > > This has O(n^2) complexity, already in such a trivial case. Once again, you are making assumptions about the physical layer that doesn't have to be true. They may be true for current mainstream SQL databases. But it is nothing in the relational model that stops you from using the most effecient implementation. Somebody could write a relational database optimized for graphics, using the availible algorithms. Since SQL is an declarative language, it tell you what to do, not how to do it. It is impossible to tell the complexity of a SQL query, from the SQL statement alone. //frebe |