Re: The IDS, the EDS and the DBMS

"erk" <eric.kaun_at_pnc.com> wrote in message news:f556e3abffeb4a81492c665557f40d2c_at_localhost.talkaboutdatabases.com...
>
> O-O itself can be used in the sense of ADTs (the data-behavior coupling),
> but also, in most modern O-O languages, it is assumed to be an organizing
> principle for all development, not just types per se. That's where things
> get dicey. Any Java app I've ever seen has static public methods, often in
> a class with nothing but static public methods. What exactly is the value
> of O-O in that? In that case, the package and class name form a useful
> namespace; none of the other features of O-O do anything but detract from
> the structure.

Do they detract, or are they simple not relevant? I'd agree that a class that exists only for the purpose of static public methods is not ideal, but what is the alternative? I think you said it exactly right with "[the class] is assumed to be an organizing principle for all development" but what's wrong with that? There's a heck of a lot of value to having an organizing principle! It's true that it doesn't suit all situations, but I'm not aware of a better one. A single global namespace for functions is decidedly worse.

The bigger problem with the binding of methods to classes is the binary method problem, but even that's not a big deal in practice. I also note that sometimes a static public method is exactly the right thing. And many "Util" classes full of static public methods are either 1) bad design that could be better expressed in a proper OO way, or 2) fixing limitations on inheritance. For example, a lot of Java projects have a StringUtil class full of methods that ought, locally, to be methods of String. I believe this issue simply indicates that OO requires a retroactive abstraction facility. (Neither C++ nor Java has this, but see for example, Scala.)

> Consider a very different paradigm: functional languages like Lisp.

(I don't think Lisp is considered particularly functional; it has no shortage of mutable state. Lisp is enough in a class by itself to just call it the "Lisp-family of languages.")

> The power of its reuse is extraordinary, and yet encapsulation and objects are
> simply ignored (to a large degree).

This is a key point.

> You can achieve much leverage and
> abstraction with no coupling of function and structure; in fact, the power
> comes from functions applied to arbitrary structures.

Hrm. I think we have to distinguish between different kinds of structure to make this statement work. Implementation and interface are both kinds of structure, or in local parlance, there is logical structure and physical structure.

Every language I'm aware of pushes the two together to some degree. Even if you build a beautifully modular program with modules separated by clean interfaces, you still have the face the fact that you've simply walled off the problem; you haven't solved it. You limit the scope of the mixing of implementation and interface.

In any event, I'm unhappy with the Lisp approach, because I am unhappy with any approach that isn't statically typed.

> Witness design patterns; how many of them simply go away in the presence
> of a properly-typed language like Haskell or ML? Don't patterns like
> Visitor and Strategy and Command cry out for functions to be treated as
> first-class language citizens? How many patterns are devoted to factory
> concepts (including Flyweight), belying the value of Java and C++-style
> "new" instantiation?

I generally agree. First-class functions are a requirement. And I haven't seen a language that gets constructors right; they are royally screwed up. (I would blame constructors specifically rather than "new", but I think we're saying the same thing.)

> O-O has much to learn (mostly its place), and I think the "ultimate
> language" will use Third-Manifesto O-O concepts for types, relations for
> data manipulation, and first-class functions for... well, I'm not sure, or
> I'd have written the damned thing by now. But I think those 3 concepts are
> all critical to development.

Relations for logical data structure, first-class functions, closures, limited local mutable state, global (but modularized!) relations, declarative integrity constraints in place of encapsulation. A rationalization of the inheritance mechanism of OO consistent with set theory.

I've been working on it since '99. I wish I could do it full time.

> > If there is more to encapsulation
> > than enforcing integrity, I'm not aware of it.
>
> Type implementation; I think Date had it right in suggesting that type
> implementations could be done in a variety of languages, and even that
> those languages might be different than those used in the rest of the
> app...

I don't see any value to Date's position here. His canonical polar/rectangular point example is uninspiring: you can't even represent (1,1) precisely in polar; you can't represent (45 degrees, 1) in rectangular. type definition is an area where you can't get away from the limitations of the underlying data structure. I think it's another place where encapsulation fails when you look too closely.

Beyond that, I don't think mixing languages is anything more sublime that a simple foreign function interface.

And Date's idea that there *not be* a way to define new types in the application language is disastrous! One of the biggest success factors of OO has been its simple and straightforward way to create new types. Creating new types in the application language is essential to the success of the language.

> > > What is needed, then, is not a "mapping" from one to
> > > the other, but rather a *unification.*
>
> I don't think they're unifiable, but I do think they're both necessary,
> and it would be nice to see a language with both.

I believe they are unifiable, but this claim demands a proof that I'm not ready to give yet.

> Microsoft's Xen is somewhat interesting, but leaves all the most important
> and valuable stuff (e.g. constraints) out...

Yeah, some of the recent MS research stuff is super-cool, but they're not paying enough attention to relations, and they're paying too much attention to XML.

Marshall Received on Fri Sep 10 2004 - 20:21:11 CEST