Hi Etienne,
Thanks for your reply... hope it generates interest. It's late, source code
provided from memory.
First answer to your question, I did some basic tests and so far, it's
working quite well... but no, I have no statistics/memeory consumption.
The idea is like a big game of ping-pong... simply send a message to an
instance and the instance will send itself to the class with the message as
long as it does not get it's return value and the return value is sent until
it gets to the original sender ;)
The current implementation is pretty simple and allows for the classic
Metaclass(class class)-Class-Object.
Basically it's a set of functions implemented within one object which
implements two methods (new and subclass) and provides a lot of basic
mechanics of objects like super, etc...
Subclasses are created like this
foo/subclass #subclass-name [
instance-variables [i]
instance-methods [
get-i: method [] [] [return self/i]
set-i: method [aValue] [] [self/i: aValue]
]
class-variables [c]
class-methods [
get-c: method [] [] [return self/c]
set-c: method [aValue] [] [self/c: aValue]
]
]
Basically, the processor generate three objects implementing the class :
subclass-name: make object! [ "class instance"
c: 5 "the real c"
class: make object! [ "metaclass instance"
interface: make object! [ "class class"
super: foo/class/interface {as object!}
c: none "the c use for instanciation"
get-c: func [self] [return self/c]
set-c: func [self aValue] [self/c: aValue]
subclass: func [self class-name source] [return super/subclass
self class-name source]
new: func [self] [return super/new self]
[...]
]
[...]
]
get-c: func [] [return class/interface/get-c]
set-c: func [aValue] [return class/interface/set-c self aValue]
subclass: func [class-name source] [return class/interface/subclass self
class-name source]
new: func [] [return class/interface/new self]
[...]
interface: make object! [ "instance class"
i: none "the i use for instanciation"
super: foo/interface {as object!}
get-i: func [self] [return self/i]
set-i: func [self aValue] [self/i: aValue]
[...]
]
]
Instances are declared with this
a: subclass-name/new
== make object! [ "instance"
i: 5 "the real i"
class: subclass-name {as object!}
get-i: func [] [return class/interface/get-i self]
set-i: func [aValue] [return class/interface/set-i self aValue]
[...]
]
note: for all instances, variables are set to none at start
Of course with all the inter-relations between object... forget about the
current probe function ;)
I wrote several implementation of this model, and the current one is quite
simple, short and understandable by most rebol newcomers. The only problem I
have with this implementation is that methods are still functions and not
objects ! and datatypes are still datatypes not objects !
---
The new implementation I was thinking about was to completely rewrite my
implementation within a Object/Behavior/Class/Metaclass hiearchy and
provides a cleaner library ! But instance methods are still functions,
instance datatypes are not objects!
--
The best implementation would be to have a class for all rebol datatypes,
including functions... which would have inherited methods allowing us to
provide basic mechanics to objects like :
aString: String/new
aString/set "ok"
aString/get
== "ok"
value? aString/value
== string!
aString/value
== "ok"
In this case, the string! datatype is embedded in a instance of String
class.
aMethod: Method/new
aMethod/specs: []
aMethod/source: []
aMethod/do
Methods of a class could be in a collection (instance of Collection with
block! as it's value datatype!), you could add, remove, rename methods...
since the instances would provide a link to the methods collection of their
class. As soon as you change a method in the class, all instances would be
affected. Etc.
Now this is a tricky part, and I cannot do that alone...
Oh and just for those still reading... have fun with the following... Maybe
it's a trail to some solutions, but I have not grokked it yet ;)
a: make object! [
name: "a"
this: func [] [return self]
]
b: make a [
name: "b"
]
a/self: b
probe a/this
probe b/this
Hmm all of this works for Core...
Best,
Chris
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of Etienne ALAURENT
> Sent: Sunday, April 07, 2002 9:04 PM
> To: [EMAIL PROTECTED]
> Subject: [REBOL] Re: REBOL : Pure OOP project ?
>
>
> Hi, Christian,
>
> I'm interested with your OO approach. Did you make tests with your lib
> (memory allocation and size, performance) ? What kind of method did you
> use to code your OO approach ? pre-processor with translation in rebol ?
>
> Christian Morency wrote:
>
> >Hi,
> >
> >Considering the low number of replies I got from the list regarding this
> >thread : Class object inheritance library interest ? and the
> interest shown
> >in the Business object versionning thread. I begin to think that either
> >Rebolers are not interested in almost pure OOP with REBOL or
> that interest
> >is only limited to one's personal project...
> >
> >For the past few months, I've been thinking about several
> implementation of
> >class object inheritance.
> >
> >I currently have one implementation : a rebol object that implements
> >inheritance through a library of func.
> >
> >I have another implementation in mind : one with the classic
> >smalltalk80-like object/behavior/class inheritance where all would be
> >implemented in base objects but would be inherited.
> >
> >But both of the above use current datatypes/functions of Rebol.
> So it would
> >not be pure-like objects.
> >
> >My latest "favourite" implementation would be to completely embed
> >datatypes/functions in objects. ie all object methods would be
> instances of
> >class Methods etc... String class would provide behavior to an embedded
> >value of datatype String!. etc... but would require more
> >path/getters/setters etc.
> >
> >I can understand that some people here are not interested in
> that. They may
> >be quite satisfied with the Self-like inheritance model of Rebol ! But I
> >would like to have the ability to change the behavior of objects
> by changing
> >their classes, and save memory by implementing a function once instead of
> >copying it everywhere. Even have a versionning system.
> >
> >This all started 4 months ago when I was about to do a project
> in Rebol. But
> >I knew I needed better OO for this project... This project has
> not started
> >yet and I wish it did.
> >
> >Again, anybody interested ? Cuz otherwise, maybe I'll be doing
> like everyone
> >else and go with what RT decided for me and use the current Object!
> >implementation.
> >
> >Best,
> >Chris
> >
>
> --
> regards.
>
> ---
> Etienne
> ---
>
>
>
> --
> To unsubscribe from this list, please send an email to
> [EMAIL PROTECTED] with "unsubscribe" in the
> subject, without the quotes.
>
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
