Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] rebol weak points (i think) Re:(5)

From: joel:neely:fedex at: 11-Sep-2000 8:05

[youpi--technologies--wanadoo--fr] 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 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-