Hello,
Thanks for this discussion. I am interested by that since I had already
posted a general question about OOP in Rebol.
I have used a language which is Toolkbok who was created by Paul Allen and
was the first Visual Language on Windows even before Visual Basic (Bill
Gates even said to Paul Allen "Your product is marvellous. I'm going to copy
it!"). 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.
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.
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 11, 2000 6:27 AM
Subject: [REBOL] rebol weak points (i think) Re:(3)
> Hi, Rishi...
>
> Just a couple of points re REBOL objects that may be of some help:
>
> [EMAIL PROTECTED] wrote:
> >
> > no. The Math/Pie you have created is an instance variable not a
> > static variable. It is associated with an instance of the class,
> > not the class itself. A static variable means that there is a
> > single copy of this variable associated with class itself. You do
> > not need to instantiate a class to use static variable...
> >
>
> 1) The distinction to which you keep referring -- "class variable"
> vs. "instance variable" -- doesn't exist at all in REBOL because
> REBOL doesn't use the class-based object model of Java or Smalltalk.
>
> There are other ways to think of objects than simply as instances of
> "classes". In NewtonScript and Self, for example, objects exist
> completely as standalone entities without any enveloping class.
> Instead, in both of those langauges, objects can have "prototypes",
> other objects to which they refer for common (or default) attributes
> and methods. In those languages, the object-to-prototype relationship
> is maintained throughout the lifetime of an object, so that changes
> to an attribute/method of an object are visible within any other
> objects that refer to the first object as their prototype (and that
> have not overridden the attribute/method involved).
>
> In REBOL, an object is a standalone entity. It may be created
> directly, using make object! ... or may be created using another
> object as a model or specification. However, it is cloned at the
> time of creation, and no longer maintains a relation to its model
> object. For example:
>
> >> ob1: make object! [
> [ attr: 23
> [ meth: func [] [print attr: attr + 1]
> [ ]
> >> kenobi: make ob1 []
> >> ob1/meth
> 24
> >> ob1/meth
> 25
> >> ob1/meth
> 26
> >> kenobi/meth
> 24
> >> kenobi/meth
> 25
> >> kenobi/meth
> 26
> >> ob1/attr: 2
> == 2
> >> ob1/meth
> 3
> >> ob1/meth
> 4
> >> kenobi/meth
> 27
> >> kenobi/meth
> 28
> >>
>
> Notice that kenobi has its own copy of attr and meth which
> are independent of those in ob1 even though no explicit overriding
> was done at the creation of kenobi . Therefore all objects are
> created equal, without any "class" vs. "instance" distinction.
> Therefore the term "static" as used in Java or c++ is meaningless
> in REBOL.
>
> >
> > The main advantage of having static variables would be to prevent
> > name collisions and to group variables/functions that act on a
> > class (not an object) together for use in a more natural way.
> >
> > The main disadvantage of having static variables is that perhaps
> > it is an unnecessary complication. But I don't think so. Maybe
> > because I come from java/javascript background. I'm still wondering
> > though if there is a way to have static variables that I don't know.
> >
> > Regardless, the main problem that I wonder about is if rebol is
> > suited for modular programming where people reuse other people's
> > functions/code. Since everything is either global or local, it seems
> > as though it would be unnatural to use rebol in this way...
> >
>
> 2) I frequently use objects in my own REBOL programming to get
> exactly the benefit you're looking for: to partition the namespace.
> Most of my REBOL source files define objects to encapsulate all of the
> variables, subordinate functions, parse pattern blocks, etc. that make
> up the details of the main idea of the script. A limited number (often
> only one!) of the functions within the object are actually intended for
> use by the clients of the object. It's a handy way to structure and
> modularize libraries of code (and DOES offer a alternative to global
> and local). I write code in this fashion when I want to reuse it
> myself across many independent projects.
>
> Hope this helps!
>
> -jn-
>
