Re: Databases as objects
Date: Sat, 23 Dec 2006 04:20:33 GMT
Message-ID: <l82jh.36535$cz.537480_at_ursa-nb00s0.nbnet.nb.ca>
Marshall wrote:
> On Dec 22, 1:12 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>
>>Marshall wrote: >> >>>On Dec 22, 9:58 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote: >> >>>>Presumably, unlike many OO proponents, Parnas thinks not all ideas in OO >>>>are good ideas. >> >>>The funny thing is, I actually like OO, such as it is. Java is a better >>>language than I otherwise would get to use. >> >>>I think it's worthwhile to identify what exactly the good ideas >>>in OO are. >>>I would propose the classic troika: >> >>> inheritance >> >>Eww! Yuck! What's good about inheritance? Reuse is good. Inheritance has >>to be the worst way ever proposed to achieve reuse, though. Generics >>provide greater reuse without introducing inappropriate coupling.
>
>
> My message should be read as an explanation of the evolution of
> my thoughts on OOP. There was a time when I thought "inheritance,
> encapsulation, polymorphism" was a tremendous achievement.
> Nowadays I see better abstractions. Fortran is a big step up from
> assembly, and that fact doesn't change when we introduce SML
> and observe that SML is a big step up from Fortran. If one is
> interested in programming language theory (PLT) then it behooves
> one to understand exactly what Fortran brought to the table, so
> that even though one does not wish to use Fortran any longer,
> one does not accidently discard some of its benefits when one
> is moving on to the next higher level.
>
> Inheritance has value. Consider that if one were given a choice
> between a fairly primitive language that did not support it and
> an otherwise identical language that did, I would choose
> the language with inheritance. The fact that we now understand
> that inheritance has problems and limitations that better
> mechanisms don't have doesn't change the fact that inheritance
> is better than nothing.
>
> Does the idealized language I have in my head have direct
> support for inheritance? No it does not. But I still ... honor
> it the way I honor the invention of Fortran. That I do so
> may appear somewhat perverse in light of how many people
> still think OO is the way, the truth, and the light. But I
> would be as much mistaken to take a reactionary position
> against them as I would be to join them. I aspire to a
> deeper, more nuanced understanding.
Fair enough.
>>> encapsulation >> >>That depends on what one means by encapsulation. >> >> >>> polymorphism >> >>Again, I suppose that depends one what one means by polymorphism. >>Quite a few things count as polymorphic in my view.
>
>
> Sure. The interesting one seems to me to be parametric polymorphism.
>
> Natural join for example is delightfully polymorphic. It takes two
> operands of the abstract type called "relation" regardless of
> what the concrete type of those relations are. One also
> wants a mechanism to write such operators oneself.
I agree. I want very much a language that allows one to express type generators and generics very easily and well.
>>>Now it turns out that "encapsulation" has two related, widely >>>used meanings: information hiding, and scoping together functions >>>and the data they operate on, which I don't have a good name >>>for besides "encapsulation." >> >>Information hiding is good. Scoping together functions and data does >>exactly the opposite of information hiding by introducing an arbitrary >>design decision the user is forced to contend with. >> >>Take the classic example of a hiring function. Does that scope with the >>employer or with the employee? Either, neither and both are all equally >>arguable in my mind.
>
> Sure. In fact this strikes me as the usual many-to-many case,
> which relational handles so well and OO doesn't.
Even for a one:many or a zero to one:zero to one relationship, the problem exists. It only gets worse for n-adic operations.
> But again, this is another case where it seems to me a step
> was taken to solve a real problem. The solution isn't the
> right one, but it did solve some problems.
I suggest it was a step that ignored fundamentals in favour of features. I further suggest you will find that focus on fundamentals at the expense of features does a whole lot better.
> The better solution I think is some kind of module system,
> perhaps like SML modules or Haskell typeclasses. In any
> event this sort of modularity question is not one I understand
> at all deeply.
I need to learn more about SML and Haskell. So much to learn, so little time.
>>>And there >>>are many kinds of polymorphism, but only one is emphasized in OO. So >>>the list becomes: >> >>> inheritance >> >>Yuck! >> >> >>> information hiding >> >>Yum! >> >> >>> encapsulation >> >>Ugh! >> >> >>> subtyping polymorphism >> >>Tasty!
>
>
> While subtyping polymorphism is the best of the list, I still
> think it's not the ideal solution. In fact, for all the convenience
> of subtyping, I've decided it's largely to be avoided. It's
> something you sort of have to have if you're stuck with a
> nominal type system, but these days I feel nominalism
> is best kept to a minimum.
Many generic operations depend on properties unrelated to subtyping. Interval generators require a type that is a total order. It doesn't matter whether the type is integer or "third thursday of the month". I am not sure what sort of type system captures the necessary traits.
> Amusingly, I see relational projection as a more general
> mechanism. If we want to construct a supertype instance
> from a subtype, simply project only those parts that one
> wishes to keep.
Projection does not affect types. Even coercing a value to a specific supertype leaves the value's most specific type unaltered.
Is-a colored point a point? Is-a it a
> color? I think "is-a" is the wrong question!
The questions are fine. The answers are "no" and "no".
I can get a
> color and a point out of a colored point with simple
> projection.
Is that project? I am ambivalent, and I have to think about it more.
I can get three different 2D points from
> a 3D point with projection. Etc. You can do this with
> easily with a structural type system, but not with a
> nominal one.
I guess I don't understand the difference between structural types and nominal types that would make a difference for the above.
>>>Inheritance is a mechanism for code reuse, and that's a good thing. >> >>Code reuse is good. Yes. Inheritance? Not so good.
>
> Again, I think inheritance is worth looking at to see what
> works and what doesn't work about it, but not as an
> example of something that was "done right."
Looking without concluding anything is not particularly useful. I look and I conclude inheritance is not so good.
> Consider the Template pattern. An abstract base class
> with a variety of final methods, parameterized by a
> small number of abstract protected methods. Each
> derived class fills in only the abstract methods.
> I find it is often the case that the majority of the code
> can go in the base class, and I get a fair degree of
> reuse thereby.
Your example presupposes the mechanism. Consider the above with generic operations parameterized by a small number of operations. The question becomes: how to enforce semantics? For example, how do we know that a given operation makes a type a total order?
> Now, I think there are higher-order functional techniques
> that achieve the same thing in a better way, but
> I still consider the template pattern a success.
Given a specific tool, one has to use the mechanisms the tool provides. Given pieces of wood to fasten, a hammer, and a box of screws, the outcome is only natural. That doesn't make a hammer a good way to drive screws.
>>>It is however a somewhat brittle mechanism, and over time the >>>OO consensus has been moving away from inheritance. >> >>That's a good thing. Eventually, they will invent relations.
>
>
> Ha ha! No doubt. And they will probably call it something like
> "extreme collections."
Nah! Collections will seem trite by then. Don't worry though: someone will coin a bright, shiny new word for them. When agile and extreme finally fall out of favour, the pendulum will probably swing toward some other anthropomorphic trait. Nimble or smart or sane or some such.
>>>Information hiding in the OO sense is a good idea because it permits >>>limiting the scope of updates, which allows some centralization in >>>the manual enforcement of data integrity. >> >>I disagree. Information hiding necessarily hides the locus of effect. >>Limiting the locus of effect is a different design goal that sometimes >>conflicts with information hiding.
>
> I can't say I particularly understood that.
Information hiding hides design decisions. It might hide the decision to alter the state of the hard disk. Or it might hide the decision to maintain an index. Or it might hide the audit trail. Those decisions do not limit the locus of effect much.
Similarly, application views hide the design of the base relations from applications. However, that does not reduce the locus of effect. The locus of effect is controlled and maintained at a different level of abstraction from the application views--namely at the level of the base relations.
>>>Once a field is private, >>>it can only be modified within a single class, and so you only have >>>one class's worth of code to look at to see all the ways that >>>field can be modified. However, a distinctly superior mechanism >>>exists in the form of declarative integrity constraints. The reason >>>this is superior is that being declarative rather than procedural, >>>it is easier to get right: you only have to state what must not >>>happen, rather than think of all the ways and all the places that >>>might happen. >> >>I am not sure I follow you here. When declarative, the only difference >>between stating what must happen or what must not happen is simply the >>negation operator. From a security perspective, it is generally better >>to state what is allowed than try to think up all the things one must >>prohibit. Constraints generally must evaluate to true.
>
> My use of the negative in the above was a mistake.
>
> We can consider three points in a continuum of integrity
> protection for a given variable.
> 1) any code any where has access and can modify it (traditional)
> 2) the variable is private to a given class and only the code
> in that class can modify it (oo)
> 3) the variable exists inside a managed container of some kind
> that support declarative integrity constraints. (declarative)
>
> Points 1 and 3 represent the endpoints of this continuum.
>
> Consider some arbitrary constraint f on x.
>
> In case 1, at each and every update site in all application code,
> when modifying x, we have to calculate a new_x, check f(new_x),
> and abort the modify if it is false. When writing future code, we
> have to know this, and maintain this discipline.
>
> In case 2, the scope of application code for which we need to
> manually insert the checks is limited to the class in which x
> is a private field, and when writing future code, the scope is
> likewise limited.
>
> In case 3, application code doesn't have to do anything,
> now or in the future.
>
> My point is:
>
> 1 < 2 < 3
>
> As an aside:
>
> Many of the bogus claims of the OO crowd against SQL stem
> from confusing cases 1 and 3. If the only equation you know is
>
> 1 < 2
>
> and 3 looks like 1 to you, you're going to come in here and
> start proposing unfortunate things like saying the database
> is a variable that should be encapsulated so that application
> code has no direct access.
I certainly agree with that.
[more agreed parts snipped]
>>Speaking of which, does anybody know of any good online references that >>teach useful statistics? As opposed to the useless crap they teach >>undergraduate engineers?
>
> I can ask around. I know some statisticians.
Please do. It's an area that is becoming increasingly important for our field. Statistics, machine learning and gaming look like the big things in the immediate future. Received on Sat Dec 23 2006 - 05:20:33 CET