REBOL : Pure OOP project ?

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

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 >Best, >Chris

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

Hi Chris, << 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... >> I thought, when I started with REBOL, that I would build an OOP infrastructure for my projects (as I had done in the past with other languages), but the more I've worked with it, the more I've moved away from that line of thinking. I'm still finding my way with REBOL, from a design and style perspective, so my view is hardly something to be taken as gospel. I know that Carl has professed that he is "recovering" from OOP and the design of REBOL shows this, while it's flexibility allows you to do OOP pretty darn well if you want. I can see building an extensive OOP system as a great challenge, and certainly possible, but I'm not sure the solution will be as elegant as it otherwise could be. Caveat emptor, I haven't built any large systems with REBOL, where OOP might really shine. I look forward to seeing your results if you pursue them. --Gregg

Hello Guys, I haven't been following this thread very closely: but here are my thoughts on the OOP approach: I'm designing a DB-based system to service a number of clients, each with a variety of needs. My hope is to service all of them with the same application, in which most of the custom code is re-evaluated global data, rather than "code". It's been a bit of a headache to keep the "side effects" down. It seems that every time I make a change, I introduce an error. More of an OOP approach would make maintenance easier, I'm sure. My experience with Ansi C (large projects) has taught me that you can do OOP with any language, but it takes some thought and design. My experience with C++ (large projects) has taught me that poorly managed or designed OOP can be a major headache and cause overly-frequent recompiles. In a word, I'd like to keep a thread on OOP going. How can I contribute? Tim * Gregg Irwin <[greggirwin--mindspring--com]> [020408 08:42]:

> Hi Chris, > << Considering the low number of replies I got from the list regarding this > [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes.

Hi Tim,

> I'm designing a DB-based system to service a number of clients, > each with a variety of needs. My hope is to service all of them > It seems that every time I make a change, I introduce an error. > More of an OOP approach would make maintenance easier, I'm sure.

> My experience with Ansi C (large projects) has taught me that you > can do OOP with > any language, but it takes some thought and design. My experience > with C++ (large projects) has taught me that poorly managed or designed > OOP can be a major headache and cause overly-frequent recompiles. > In a word, I'd like to keep a thread on OOP going.

> How can I contribute?

Hi, Forgot to say something about my current implementation ... The worst/best part is that it does not support function refinements ! I can understand the power of refinements, and have even used it for some small scripts... but at the same time I don't like it... I have found that most of the time, refinements are simply booleans with further arguements. Furthermore, they are usually used in functions that does too much ! I prefer small functions that do less... Best, Chris

Hi Gregg,

> I thought, when I started with REBOL, that I would build an OOP > infrastructure for my projects (as I had done in the past with other > and style perspective, so my view is hardly something to be taken > as gospel.

> I know that Carl has professed that he is "recovering" from OOP and the > design of REBOL shows this, while it's flexibility allows you to do OOP > haven't built > any large systems with REBOL, where OOP might really shine.

> I look forward to seeing your results if you pursue them.

* Christian Morency <[chrismorency--videotron--ca]> [020408 15:13]: Hi Christian:

> I gather that your functions must do a lot of code ? OOP/Methods, when > clearly designed, limits development by favoring reuse. This is one of the > thing I need for my project.

> > My experience with Ansi C (large projects) has taught me that you > > can do OOP with > > How can I contribute? > Any ideas on how OOP could work in Rebol is welcomed...

Hi,

> > I gather that your functions must do a lot of code ? OOP/Methods, when > > clearly designed, limits development by favoring reuse. This is > preoccupation the metaphor. > From where I sit, 'scheme is sort of a new metaphor, isn't it?

> Given tha above thoughts on the "metaphor" here's another > thought or two: > 1)Rebol lacks a cohesive set of resources such as is offered > by Python or Perl libraries

> 2)Some entity approved, monitored and made other decisions > as to the makeup of those resources.

> 3)The makeup of those resources should (I think) be comprised > of discrete components with some degree of re-usability.

> 4)One of my obstacles (regardless of the language involved) > is that > ==>> greater re-usability = more difficult configuration > ==>> lesser re-usability = easier configuration.

Hi Chris, I've been doing OOP stuff heavily for the past 7 years (though SmallTalkers and Eiffel folks could argue about the OOP-ness of it :) and I'm constantly amazed at the code I find myself writing in REBOL compared to what I would have written before. IMO, of the "big 3", Encapsulation provides 49.5% of the value, Polymorphism is 49.5%, and Inheritance the rest. :) These, of course, are my opinions based on my experience. YMMV. For large projects, the value of Encapsulation goes up. The judicious use of Polymorphism can help to keep projects from growing. << I can understand the power of refinements, and have even used it for some small scripts... but at the same time I don't like it... I have found that most of the time, refinements are simply booleans with further arguements. Furthermore, they are usually used in functions that does too much ! I prefer small functions that do less... >> I've always liked the ability to provide optional arguments. Like other features, it can be abused, but, done right, they can help to reduce the number of routines you have to deal with and actually provide quite a bit of value. For example, I have a ROUND function that has *6* possible refinements (with one of them probably going away as it's semi-redundant with another). Normally I would run screaming from something like that but I looked at the alternative and like this solution better. Here's the help for it. USAGE: ROUND value /up /floor /ceiling /truncate /places pl /to-interval interval DESCRIPTION: Rounds numeric value with refinements for what kind of rounding you want performed, how many decimal places to round to, etc. ROUND is a function value. ARGUMENTS: value -- The value to round (Type: number money time) REFINEMENTS: /up -- Round away from 0 /floor -- Round towards the next more negative digit /ceiling -- Round towards the next more positive digit /truncate -- Remaining digits are unchanged. (a.k.a. down) /places -- The number of decimal places to keep pl -- (Type: integer) /to-interval -- Round to the nearest multiple of interval interval -- (Type: number money time) The body of the routine is about 20 lines or so, which includes the handling for all the refinements. Breaking it into separate FLOOR, CEILING, TRUNCATE, and ROUND-UP (statistical rounding is the default) I would have 5 functions, each with about 15 lines of code in their bodies, all *nearly* identical, and nothing to tell you they're similar (except experience of course). That said, this is currently the best example I have as an argument *for* refinements. I haven't deployed a system that used them heavily and then needed to be updated, and there are certainly valid arguments *against* them as well. --Gregg

Hear hear! Better VID libraries. But sharing content is not so simple. Effectively sharing your work means documenting it well, making it clearly available and visible on your site, and dealing with version conflicts. All of this requires a lot of effort. To do all this with an experimental project sometimes seems like it could be a pointless waste of time. IOS is better at all this than rebol/view, so we need to build tools to help us document and share files. But to make good tools, um, we need good VID libraries. It's a circular dependency. In my view, the single most needed tool for app development is a good list style. I plan to make one after I fix up my grid some more. (I saw Robert M. Muench's interesting problem and I will keep that in mind). Then we can make file-listers, directory selectors etc. much easier. With well-working gadgets everything will open up, as good apps depend on good gadgets. Anton.

> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of > Anton > Sent: Tuesday, April 09, 2002 8:25 AM > To: [rebol-list--rebol--com] > Subject: [REBOL] Re: REBOL : Pure OOP project ?

> Hear hear! Better VID libraries. > But sharing content is not so simple. > Effectively sharing your work means documenting > it well, making it clearly available and visible > on your site, and dealing with version conflicts. > All of this requires a lot of effort.

> To do all this with an experimental project sometimes > seems like it could be a pointless waste of time.

> But to make good tools, um, we need good VID libraries. > It's a circular dependency.

> In my view, the single most needed tool for app > development is a good list style. I plan to make > one after I fix up my grid some more. > (I saw Robert M. Muench's interesting problem and > I will keep that in mind).

Hi Gregg,

> I've been doing OOP stuff heavily for the past 7 years (though > SmallTalkers > and Eiffel folks could argue about the OOP-ness of it :) and I'm > constantly > amazed at the code I find myself writing in REBOL compared to what I would > have written before.

> IMO, of the "big 3", Encapsulation provides 49.5% of the value, > Polymorphism > goes up. The judicious use of Polymorphism can help to keep projects from > growing.

> I've always liked the ability to provide optional arguments. Like other > features, it can be abused, but, done right, they can help to reduce the > the help for > it.

Hi,

> Hi, concerning OOP for Rebol IMO we shouldn't take it to > dogmatic. I'm still > aggregated" pattern > and it seems to be quite OK.

<snip> > Yes. Starting with a widget collection that is plug-in compatible > could be a > pragmatic starting point. For this we need one (!) and only one person to > coordinate it.

Hi,

> In my view, the single most needed tool for app > development is a good list style. I plan to make > one after I fix up my grid some more. > (I saw Robert M. Muench's interesting problem and > I will keep that in mind).

> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of > I agree that OOP is not the key to rebol-usage-pattern, at the moment ;) But > for large projects it could benefits.

> Could you further explain your "aggregated" pattern for object in rebol ?

> Each widget should be developped by one person, but I think the coordination > could be from the mailing list...