Starting from the feeling that the environment for object-oriented
programming must be a object-oriented operation system and a
object-oriented OS must be a lot different to today's OS I've done a
lot of theoretical work to locate the needed differences.
In that way I came up with some surpricing results. This is not the
time and place to explain. (There is something to explain, no paper is
ready (yet) and by now not all the work is done. A lot of it is not
ready even inside of my head.)
The main-point I've figured out is, that a "good" entity X (where X is
programming language, a single program, a system of programs, a OS or
anything else related) is much more comparable to formal and even
natural language than common expected. Don't tell me that's a old hat.
I don't talk about syntax, but the semantic. Moreover I got some
criteria (almost ready to use) to describe what "good" means.
(Something to mensure "goodness" no matter of taste.)
But know I need to evaluate, whether it is really usefull or I lost
the ground. Therefor I need your comments:
(A short story beside, just to explain why I post at this early
stage of development with subject RFC: today I started to read the
CLOS-metaobject-protocol-spec in an attempt to classify it in my
way. (I've never read anything about CLOS before, because I dislike
the ()-generating syntax of lisp.) A lot of things fit in. Something
appears to be subject to improvement. Moreover they pointed these
things out as done by intuition.
When I realized that I was going to handle things so easy, a lot of
intelligent people have thought a long time about, I got the fear
that I may be wrong. Or did I got a cool thing?)
1) Q: What do you think a OS environment for OOP should provide?
2) statement:
A object must not know anything about the context it will be
used in.
(the term context herein *excludes* meta-level-dependencies)
Refer to next point.
3) statement:
To "optimize" something means to break the rule above.
The result of an otimization is something more complex (it
incorporates knowledge of it's usage) with the same functionality.
In opposite you'll often get something optimized, when you break
it down into parts. Each of them are simpler and don't know
anything about the context they are used in. But this is not true
optimization, this means to find a better abstraction. (So far it
is much more valuable than optimizing.)
4) statement:
A object must not know anything about details it's
metaobjects.
That means it should never change it's own behavior by
invoking metabojects.
I think that will be the point, most people will argue about and I
look forward for that. But I think I'm right:
If a object assumes any details about it's meta-level than it will
be unable to operate under a different meta-level. More if it
knows details, than the abstraction, goten by the meta-level ist
lost.
How to operate in a clear way with meta-objekts: there must be a
second objekt, what knows about the desired object and it's meta
but doesn't know anything about the internals of both. That has to
talk about the relations.
5) The complexity of a any system depends on the amount of terms
involved.
The more complex a system is the less it can be ruled (used).
Here I need 1st to say what amount of terms means: at any point of a
description there is a set of "words" allowed by the syntax and a set
is forbidden. (Example: at some point of a function the syntax allows
a variable-name; if you have 10 variables there are 10 terms.)
By now I don't have exact numbers how much is good. It seems to depend
loosly at 10 to the power by x whith:
x<=1)
The system is very clear. There are either clear to understand facts
(axioms) or formal proofable things.
Examples:
mathematical or physical theories,
the number of formal arg's and var's in functions,
the number of people one supervisor should have,
even the number of *good* friends of a person (yes)
1<x<2)
The system is very good to use, but you have to use your head.
Most, there are formal proof's but somtimes not. Usualy you'll not
give a formal proof but a test.
Examples:
keywords in programming languages,
system-calls in successiv OS,
the amount of methods associated with a complex object,
the number of people one person can lead,
2<x<3)
The system is usable, but it is real work. You have to learn a lot and
so there are gurus for every system of this complexity.
No-one will ever give a good proof. It is almost sure, that the system
will have some bugs.
Examples:
API's like MS-Windows, Xlib, ...,
bad OOP with exploding classes,
the number of people you can remember the name for
3<x<4)
It getting hard to rule. A large amount of people have to work on and
the work is slowing down. No single person knows all parts.
Examples:
software developed further and further for long time (like X-Server),
x>4)
It can't be full ruled, the best you can get is a good feeling.
Examples:
natural language,
chinese alphabet,
If you can give me some good examples let me know.
So far today.
Please send or cc your comments to me by mail. The news-system here is
not as stable as it should be...
--
-----------------------------------------------------------------------------
Joerg Wittenberger
Rietzstr. 32b
01139 Dresden
Germany
email: ··@ibch50.inf.tu-dresden.de
···@mail.inf.tu-dresden.de
WWW: <a href=http://www.inf.tu-dresden.de:8002/people/jw6/top.html>jerry</a>
PGP PUBLIC KEY: available on request or by finger
Damned, now I know what kind of environment you need for *any*
writing. SILENCE and less than 5 desks in a room.
I forgot to mention one point in my posting. I would better go as
point 5 but now it's 6:
6) Not all programming can be done as OO if it should be done in the
best structure for the human reader.
(Don't reply you program to be read by a machine. Then you should
program assembler or even better encode the bits by hand!)
There are 2 things related:
a) For imagination: Terms like function, procedure, relation are not
invented for the need of computers, they are adopted from natural and
scientific language.
b) To define functions (most of them) and relations there is a typical
way:
You assume 2 or more objects, combine them in a syntactical way and
now you define for this aggregation at least one more object,
computable from the objects started from.
The computation doesn't belong to any of the objects started from.
It belongs to the aggregation, to a syntactical production.
If it would belong to one of the objects started from, this object had
to know something about it's context -- bad OOP.
If it would belong to the resulting object, than lets think about the
eql-relation. The result is boolean. Now boolean had to know about all
the comparable objects. Hot air.
But the OO-paradigm requests the computation to be a method of one of
the objects. That is, where OO fails to serve what it should do.
OO realy needs a extention "back" to syntax-oriented programming and
anywhere else.
Here are some points which come from this lack of OO-paradigm:
Most OO-Languages still have operators. There usage hides this bad
construction.
The method-definition for operators are very fancy.
(If there is somthing like "a+b": belongs the method called to
a or b? Ok, the language defines that. But which reason gives
the decision?)
Python gets flooded these day with magic __*__ functions for this
reason.
C++ (which doesn't force you to program good OO but gives you the
chance) carries mechanisms to break the OO-paradigm. Have a look in
the iostream-library. The "<<" operator for example is heavily use and
overloaded. But it's definition isn't a method.
--
-----------------------------------------------------------------------------
Joerg Wittenberger
Rietzstr. 32b
01139 Dresden
Germany
email: ··@ibch50.inf.tu-dresden.de
···@mail.inf.tu-dresden.de
WWW: <a href=http://www.inf.tu-dresden.de:8002/people/jw6/top.html>jerry</a>
PGP PUBLIC KEY: available on request or by finger