[EMAIL PROTECTED] wrote:
> ... Toolbook has very advanced OOP concepts and at the same time
> much simpler and more elegant than other languages. But the only
> thing that was really awful was that he coped with object directly
> without dynamic linking to some sort of prototype or class or
> whatever you want to call the ancestor. For building complex
> program with such a model is very easy but to maintain and reuse
> components in multiple projects all alive is very difficult
> without creating our own framework of MFC like in Visual C.
>
> I have exactly the same problem in Visual Basic which only knows
> Interfaces but completly ignore inheritance which is implemented
> in Visual C. So if you want to make some sort of industrial
> softwares (automate part of software conception) with the classic
> document-view architecture in VB and Rational Rose you will have
> tremendous difficulties.
>
You can use object composition, as in the following (hypothetical,
built-by-hand) fragment of code.
parent-object: make object! [
attrp1: 23
methp1: func [n [integer!]] [attrp1: attrp1 + n]
methp2: func [] [print ["now up to" attrp1]]
]
child-object-1a: make object! [
_parent: parent-object
attrc1: 10
methc1: func [n [integer!]] [attrc1: attrc1 - n]
methp1: func [args... [...whatever...]] [_parent/methp1 args...]
methp2: func [args... [...whatever...]] [_parent/methp2 args...]
]
child-object-1b: make object! [
_parent: parent-object
attrc1: 10
methc1: func [n [integer!]] [attrc1: attrc1 - n]
methp1: func [args... [...whatever...]] [_parent/methp1 args...]
methp2: func [args... [...whatever...]] [_parent/methp2 args...]
]
;... as many as you want
child-object-2a: make parent-object [
attrc1: 10
methc1: func [n [integer!]] [attrc1: attrc1 - n]
]
child-object-2b: make parent-object [
attrc1: 10
methc1: func [n [integer!]] [attrc1: attrc1 - n]
]
;... as many as you want
All of the "child-object-*" objects have the same interface, but
the "child-object-1*" objects all delegate methp1 and methp2
to a common, shared, distinct object. In practice, parent-object
is now fulfilling the dynamic role (NOT the initialization role)
of a class in such languages as Java and Smalltalk.
(The reason I emphasized "built-by-hand" is that you could write
metaREBOL code to automate much of the construction, but diving
into that level of detail right now would only obscure my point.)
However, all of the "child-object-2*" objects all have no class ;-)
since each is initialized with a COPY of the components of the
spec object, but each goes its merry way immediatly thereafter.
If you REALLY want to get obscure (and what good OO programmer
doesn't ;-) the above technique obviously extends to simulate
multiple inheritance.
child-object-3: make object! [
_mama: parent-object-1
_papa: parent-object-2
meth-m1: func [args... [...whatever...]] [_mama/meth-m1 args...]
meth-m2: func [args... [...whatever...]] [_mama/meth-m2 args...]
meth-p1: func [args... [...whatever...]] [_mama/meth-p1 args...]
meth-p2: func [args... [...whatever...]] [_mama/meth-p2 args...]
;... etc.
]
I'll stop there, as I can't come up this early in the morning with
good names for THREE parents... ;-)
>
> So I think I will encounter exactly the same problem in Rebol although
> I could make an architecture of messages sending that would implement
> some sort of inheritance as I did in VB. But as for now I didn't see
> enough advanced documentation in Rebol to be able to do it. The
> documentation is very well done but lack some advanced explanation
> about conception. So I look at some examples in rebol.org but still
> didn't see any example of architecture framework.
>
Someone once described FORTH as "not a programming language, but a
programming language construction kit". I think that there's more than
a grain of truth in applying that description to REBOL as well. It's
just a matter of tradeoffs.
Carl has given us a highly flexible, customizable, and extensible
language. The cost of all those virtues is that if you really WANT to
make REBOL code behave according to your mental model of language X
(for all X ;-) you must do some of the plumbing yourself. That usually
requires fairly sophisticated knowledge of BOTH languages.
-jn-
