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

REBOL : Pure OOP project ?

 [1/17] from: chrismorency::videotron::ca at: 7-Apr-2002 17:00


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

 [2/17] from: etienne:alaurent:free at: 8-Apr-2002 3:04


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
<<quoted lines omitted: 29>>
>Best, >Chris
-- regards. --- Etienne

 [3/17] from: chrismorency:videotron:ca at: 7-Apr-2002 23:19


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

 [4/17] from: greggirwin:mindspring at: 8-Apr-2002 9:46


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

 [5/17] from: tim:johnsons-web at: 8-Apr-2002 9:00


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
<<quoted lines omitted: 19>>
> [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes.
-- Tim Johnson <[tim--johnsons-web--com]> http://www.alaska-internet-solutions.com http://www.johnsons-web.com

 [6/17] from: chrismorency:videotron:ca at: 8-Apr-2002 18:44


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
<<quoted lines omitted: 3>>
> 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.
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 > 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.
Me too ;)
> How can I contribute?
Any ideas on how OOP could work in Rebol is welcomed...

 [7/17] from: chrismorency:videotron:ca at: 8-Apr-2002 18:44


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

 [8/17] from: chrismorency:videotron:ca at: 8-Apr-2002 18:39


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
<<quoted lines omitted: 3>>
> and style perspective, so my view is hardly something to be taken > as gospel.
I find myself in the same situation as you (my view is not to be taken as gospel), however I do find myself in a position where my project would benefit from a "better" implementation of OOP for Rebol... And furthermore, I have decided that if I need such an infrastructure, better share with my fellow rebolers.
> 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
<<quoted lines omitted: 4>>
> haven't built > any large systems with REBOL, where OOP might really shine.
I know about Carl's recovering, we have yet to know if he has fully recovered ;) I can understand his point of view and respect his decision for Rebol. However, I'm a bit of a doubting Thomas, and since I daily work in OOP and I daily see it's results and qualities for a delivered product, I'm a believer. Furthermore, I'm quite happy he has offer us basic OOP functionality in Rebol, if it wasn't for these, I would have probably liked Rebol for small projects/scripts, but not for big ones/applications and I have a big one in mind ;) Why Rebol and not another pure OOP languages ? Because I like Rebol, I'm a believer !
> I look forward to seeing your results if you pursue them.
Thanks, I hope I can achieve an infrastructure which will interest others ! Best regards, Chris

 [9/17] from: tim:johnsons-web at: 8-Apr-2002 18:49


* 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.
I kind of agree with Carl's notion that OOP is overrated. Perhaps the metaphor of "object" needs to change. That might eleviate preoccupation the metaphor. From where I sit, 'scheme is sort of a new metaphor, isn't it?
> > My experience with Ansi C (large projects) has taught me that you > > can do OOP with
<<quoted lines omitted: 5>>
> > How can I contribute? > Any ideas on how OOP could work in Rebol is welcomed...
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. "miles to do before I sleep" r. frost -tj- -- Tim Johnson <[tim--johnsons-web--com]> http://www.alaska-internet-solutions.com http://www.johnsons-web.com

 [10/17] from: chrismorency:videotron:ca at: 9-Apr-2002 0:27


Hi,
> > I gather that your functions must do a lot of code ? OOP/Methods, when > > clearly designed, limits development by favoring reuse. This is
<<quoted lines omitted: 4>>
> preoccupation the metaphor. > From where I sit, 'scheme is sort of a new metaphor, isn't it?
Maybe OOP has been overrated, but I prefer to believe that it's "proper" use has been under-exploited. Since the 60's, we've been challenged by the folder metaphor, the desktop metaphor, the object metaphor, the "window" metaphor and now we get to dialect metaphor with Rebol. What if the metaphor should be organic ? One thing I think is that OOP is NOT Java and not C++, even with all the hype around them. Maybe the Self-like of Rebol's object inheritance is the way to go... but I don't like the idea of having 20 copies of the same method in 20 instances !
> 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
I have several times mentionned that Rebol developers should build libraries and share them. This was the goal. If we are not to write in OOP, at least write simple genereic libraries !
> 2)Some entity approved, monitored and made other decisions > as to the makeup of those resources.
You are suggesting we should have some sort of developer board, maybe independant from RT ? To that I agree. Furthermore, functions in those libraries should provide simple implementation with proper documentation. I prefer to see the following print-string: func [aString] [print aString] than ps: func [s] [print s] --->>> I think we actually see too much of these in current Rebol scripts.
> 3)The makeup of those resources should (I think) be comprised > of discrete components with some degree of re-usability.
Some, I would say major degree of re-usability... I can't believe that everyone's currently fighting with VID in their own personal corner and not sharing content. We need to have better vid libraries !!!
> 4)One of my obstacles (regardless of the language involved) > is that > ==>> greater re-usability = more difficult configuration > ==>> lesser re-usability = easier configuration.
I don't think configuration is that difficult. The most difficult is deciding what is going where... and what is the simplest and most understandable implementation. If Rebol is to succeed in appearing to everybody (from a children to a grandmother), is with simplicity ! Some of the current implementation of Rebol is not really "simple" to the common man. We need to address this in some sort of collective work ! RT gave us tool, but they never said we can't change or build on them ! Best, Chris

 [11/17] from: greggirwin:mindspring at: 9-Apr-2002 0:03


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

 [12/17] from: anton:lexicon at: 9-Apr-2002 16:25


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.

 [13/17] from: robert:muench:robertmuench at: 9-Apr-2002 10:39


> -----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 ?
Hi, concerning OOP for Rebol IMO we shouldn't take it to dogmatic. I'm still finding my own useage pattern for Rebol. At the moment I don't think OOP is the key to the Rebol-usage-pattern. I'm focusing on an "object aggregated" pattern and it seems to be quite OK.
> 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.
That's right, and the hardest problem IMO is to make the snippets plug-in compatible. I never like libraries, frameworks etc. where you only have an all-or-nothing choice. I want to use stuff selectively. I'm currently trying to achieve the reuse-by-plug-in pattern with the object-aggregated approach.
> To do all this with an experimental project sometimes > seems like it could be a pointless waste of time.
It depends on. We all have to find the right way to work with Rebol. For this I always create short test-programms to get a feeling for the best way (and if I don't have time or leisure I ask the mailing list ;-)).
> But to make good tools, um, we need good VID libraries. > It's a circular dependency.
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.
> 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).
Thanks a lot. If you start contact me, as I'm trying out different things at the moment. Robert

 [14/17] from: chrismorency:videotron:ca at: 9-Apr-2002 19:43


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.
I daily think in C, Smalltalk and Rebol. I constantly find myself saying, In rebol I would... , "In smalltalk I would..." and "In C I could but...". The thing with Rebol is that it's small, it's fast, it's multi-platform ! I am too amazed at the way I code in Rebol. It's so simple... and it works ! The only problems I have encountered is with VID, but that may be more because of my laziness ;)
> IMO, of the "big 3", Encapsulation provides 49.5% of the value, > Polymorphism
<<quoted lines omitted: 3>>
> goes up. The judicious use of Polymorphism can help to keep projects from > growing.
For me, of the "big 3", Encapsulation provides 45%, Inheritence 45% and polymorphism 10%. Of Encapsulation, I would say that the "data access" value is 80%, private/public 20%... Personnally, I find the late to be something more of alerting the developer to what he is doing... but otherwise, he should know ! For Rebol, I don't think encapsulation (private/public) is that important. Inheritence, polymorphism and data-access is more important and is already implemented with the make object! object. Some may argue that when super-object's behavior has changed, sub-objects should too... I don't even think that's the problem. My main problem with the current implementation is that code is copied from instances to instances (sub-objects!)... Anybody ran stats on memory consumption with objects ? If methods would be objects in Rebol and would make the difference between the self of the object and the self of the method ! Maybe all this could be resolved with a new datatype? for Core 2.6 ?
> 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
<<quoted lines omitted: 7>>
> the help for > it.
I grok how refinements can be useful ;) I've used them myself, and for procedural programming, it's really awesome, but for objects... hmm I'm not sure... Best, Chris

 [15/17] from: chrismorency:videotron:ca at: 9-Apr-2002 19:57


Hi,
> Hi, concerning OOP for Rebol IMO we shouldn't take it to > dogmatic. I'm still
<<quoted lines omitted: 3>>
> aggregated" pattern > and it seems to be quite OK.
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 ?
<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.
Each widget should be developped by one person, but I think the coordination could be from the mailing list... Let's take an example. Today I want to implement a widget. I come to the list and say. I have the time and the interest to build a widget. Now, anybody got ideas on how it could be done... how it would work... who has already tried it, etc... Let's share user story. Then the person goes and build the widget, taking in account what has been discussed, while limiting the widget to what it should do actually... the basic/generic stuff. That person could become the coordinator of this widget and widget based upon it's design... etc. Maybe it's not a good idea, but I think it would produce something good. democratic will lead us to generic ;) Best, Chris

 [16/17] from: chrismorency:videotron:ca at: 9-Apr-2002 19:48


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).
In my view, the single most needed tool for app development is a rebol app development environment ;) Best, Chris

 [17/17] from: robert:muench:robertmuench at: 10-Apr-2002 9:51


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 4>>
> I agree that OOP is not the key to rebol-usage-pattern, at the moment ;) But > for large projects it could benefits.
OOP didn't solved the software-component-reuse problem, it makes it sometimes a bit easier if you have a good designer in your team. But anyway... it's an option and maybe we have it available one day.
> Could you further explain your "aggregated" pattern for object in rebol ?
Well, it's no rocket sience. At the moment I design my reblets like this: 1. I use objects for aggregating data. These objects are version-controled. 2. I add business-object-evolution code. This code can transform my data objects from one version to the next. So updating my inner data structure won't break any old data-files. IMO that's very important, if you publish several versions, you can assure that all of these will be used somewhere. Don't expect people to always use your latest version. 3. I use one object for all the VID stuff for one mask/dialog/frame. This includes the layout and all kind of supporting functions needed. Further I only have two functions to travel from objects to gui and backward: object_to_gui and gui_to_object. 4. I have a set of global functions that are generic enough so that these can be used from all GUI objects. Like finding, adding, deleting, changing an object. For VID I use the sub-panel pattern. I have one main window with a box that get's resized and assigned new layouts.
> Each widget should be developped by one person, but I think the coordination > could be from the mailing list...
Sorry, but I don't agree. IMO the widget should be developed by all of us who are interested but being coordinated by one person. The coordination is the critical part as you have to check that the widget will be plug-in able into the bigger picture, the RSL (Rebol Standard Library). For me the concept how to use Rebol, create libraries and lightweight frameworks (that's in short design- and programming style and guideline) is the base to start with. If we got a (democratic) agreed concept building all the widgets should be quite fast with all the people here. At the moment I have to read the widget sources, alter them to fit into my architecture, alter words atc. But if the widget gets updated... I'm lost and need to start over again. Robert

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted