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

Rebol Framework suggestion

 [1/12] from: lmecir::mbox::vol::cz at: 11-Sep-2001 22:52


Hi,
> > Usually in OOP, the Class defines the methods and properties of an > > object and the objects will implements their own properties based on > > the class... > > Not always. What you define above is class based OOP. There is also
generic function based oop as used by languages like Common Lisp and Dylan. Warning, longish discussion on differences between the different ways of doing OOP below.
I tried to experiment with both possibilities in Rebol, but the Generic Function Based OOP seemed more promising for Rebol, although a little bit more complicated to implement. Added the %methods.r (the class-based OOP experiment) to my Rebsite. It is more than a year old, don't know if it could be used for anything serious,... Regards Ladislav

 [2/12] from: doublec:acc at: 12-Sep-2001 10:06


You might like to take a look at tiny clos: http://www.parc.xerox.com/csl/groups/sda/projects/oi/software.html This is an implementation of the generic function approach in Scheme - it's kind of a combination of Dylan and CLOS in terms of functionality I believe and shouldn't be too difficult to convert to Rebol. Chris.
>>> [lmecir--mbox--vol--cz] 09/12 8:52 >>>
I tried to experiment with both possibilities in Rebol, but the Generic Function Based OOP seemed more promising for Rebol, although a little bit more complicated to implement. Added the %methods.r (the class-based OOP experiment) to my Rebsite. It is more than a year old, don't know if it could be used for anything serious,...

 [3/12] from: chrismorency:videotron:ca at: 10-Sep-2001 20:56


Hi,
> IIRC, Ladislav Mecir created methods.r some time ago? It allowed > you to have classes, objects, methods, etc. IIRC ... I just wonder, > if it is still available anywhere? :-)
I would be interested in looking at this.
> On the other hand - I programmed in CA Visual Objects. I read > many papers on object orientation, and while I am not too good > programmer, I sometimes don't fully understand all the fuss > about object orientation and its advantages - hey, the result is > some executable code, user doesn't care, so the only one > question is - programmer's efficiency.
Hmm, I won't go into that discussion since I'm neither a big advocate of either method (OOP or functional/procedural), suffice to say I prefer OOP for my personal taste, and Rebol offers that so that's a + for me ;-)
> With Rebol, you get nice space navigation, you have very dynamic > binding on demand. So, if I understand things correctly, you have > much wider freedom to define things exactly as they fit your > solution. btw: as of Core 2.5, object creation functionality was > slightly extended - although I never found practical reason to > use it :-) http://www.rebol.com/docs/core25.html#section-11
Thanks for the reminder for the link ;-) The way objects are implemented in Rebol may use a lot of memory AFAIK. Usually in OOP, the Class defines the methods and properties of an object and the objects will implements their own properties based on the class... however they will point to the methods in the class ! Also, a method which is not implemented in a sub-class will be inherited from the one above, not copied... My main concerns is not only related to memory issue but to debugging also... I would like to probe an object and have the possibility to only see what I want, ie the current properties and maybe the methods that are define at this level... knowing that the others are inherited.
> Would be nice to have. I just wonder what happened to Carl's > Rebol/Author ....
Hmm, rings a bell, but that might have been mentioned when I was not active with Rebol as I am now...
> Yes, style I miss most, is fast, nice tree-view ... > But reusability as you describe it, has very low in common with object
<<quoted lines omitted: 5>>
> locally, and if > not available, script would try to download it from the library ...
Well well-defined generic object can be reused, I mean a lot of languages have libraries which are re-usable ! As for the needs, requires headers, I find them instructive, but would appreciate if rebol made sure these were loaded in memory...
> Another usefull thing would be probably to extend help to work > upon objects - to > autocollect help info from it's functions, print list of words > and their values, > etc. > > What would I like to see maybe even more, - more dialects ...
Who doesn't *smile* best, Chris

 [4/12] from: chrismorency:videotron:ca at: 10-Sep-2001 21:02


Hi, I'd be very much interested by this script !!! (methods.r) Best, Chris

 [5/12] from: chrismorency:videotron:ca at: 10-Sep-2001 21:02


Hi,
> I'm coming to REBOL from VB and I'm used to having an IDE myself. While > there are certain things I would love to have in an IDE for building REBOL
<<quoted lines omitted: 3>>
> revolutionary and I think, to take full advantage of what it can do, we > need to focus on the end rather than the means.
Well, I come from a VB background too, but if you take the example of SmallTalk, AFAIK the mere windows, buttons, sliders, visual objects we are daily using are coming from the Alto Palto Xerox era, and these visual objects were first implemented for the SmallTalk development environment (I may be wrong here), but that's not the point. I would prefer to see a IDE built in Rebol for Rebol than any other thing, I would prefer that because it makes sense IMHO !
> Imagine your REBOL script is an agent running around the internet. > Will everyone you want to talk to be using the same type > library?
No, to that I must agree ;) however, what if it does ? I mean, one of the beauty of the try? is exactly this !
> There will be times that we want to try to guarantee correctness > to the n-th degree and tightly control things but what if we
<<quoted lines omitted: 4>>
> and dialects fill the position of IDL/ODL stuff but, wow, what a > difference that would be IMO.
Dialects could indeed provide a great link between IDL and ODL. I haven't been looking at dialect yet, I should put my mind to it soon ;-)
> I would love to help build some reusable libraries for REBOL but I don't > know what the best approach might be due to my inexperience with it.
<<quoted lines omitted: 3>>
> really use all the time. REBOL has features built in which will > eliminate a lot of the libraries I've written for myself over time.
Consider me at the same point you are... still learning, but I'm still planning, and willing to share, build with others...
> Rather than try to put a big OO layer on top of REBOL, I'd say "think > small". What are *concrete* 3 things you rely on every day, or in > every project? By concrete I mean avoid abstract concepts like > inheritance. Reading ASCII files, mapping COBOL > records, designing GUIs, one-off code generators, that kind of stuff.
Well, maybe the project I'm working on wasn't really meant to be developped in Rebol, but in a sense I know it is... light, distributed, internet based... Which language would help me build this better than Rebol ?
> Just some thoughts (from my position of near ignorance <g>).
Good points to my suggestion (from my own position of near ignorance *g*). Chris

 [6/12] from: doublec:acc at: 11-Sep-2001 14:17


> Usually in OOP, the Class defines the methods and properties of an > object and the objects will implements their own properties based on > the class...
Not always. What you define above is class based OOP. There is also generic function based oop as used by languages like Common Lisp and Dylan. Warning, longish discussion on differences between the different ways of doing OOP below. In generic function based OOP the methods do not belong to a class. All arguments passed to a method are used in resolving what method to call. This is known as multiple dispatch. It's similar to C++ overloading, but determined by run time types rather than compile time types. So for example, in C++: class Window {}; class Event {}; class ApplicationWindow1 : public Window {}; class LeftClickEvent : public Event {}; void HandleEvent(Window* window, Event* event); void HandleEvent(ApplicationWindow1* window, LeftClickEvent* event); Event* event = new LeftClickEvent; Window* window = new ApplicationWindow1; HandleEvent(window, event); This calls HandleEvent(Window*, Event*) rather than HandleEvent(ApplicationWindow1*,LeftClickEvent*) as you might want. This is because the dispatch is based on the compile time type of the arguments. Now you could make HandleEvent a virtual function to get run time dispatch. But then the dispatch occurs only on the first argument, the Window type. How to also dispatch on the second argument? For example, in C++ with virtual functions: class Event {}; class LeftClickEvent : public Event {}; class Window { public: virtual void HandleEvent(Event* event); virtual void HandleEvent(LeftClickEvent* event); }; class ApplicationWindow1 : public Window { public: virtual void HandleEvent(Event* event); virtual void HandleEvent(LeftClickEvent* event); }; Event* event = new LeftClickEvent; Window* window = new ApplicationWindow1; window->HandleEvent(event); Again, you might expect HandleEvent(LeftClickEvent*) of the ApplicationWindow1 class to be called but this does not happen. Instead HandleEvent(Event*) of the ApplicationWindow1 class is called. Why? Because the static type of the second argument is an Event*. The run time type is a LeftClickEvent*. Method dispatch on arguments for C++ methods are for the static type. The other problem occurs with every Window class needing to know about every Event class. When a new Event class is created you must go back and modify every existing Window class to add a handler for it. Note that Java and Smalltalk have similar problems as C++ here. This is the main reason for the existance of the Visitor pattern - workarounds for the lack of multi method dispatch. A generic function based OOP system dispatches all arguments on the run time type of the arguments, and allow extending the methods of a class without having to go back and re-edit the class. This is because methods do not 'belong' to a class. They belong to 'generic functions' which contain collections of methods. When a generic function is called all the methods that belong to that generic are examined and the method that takes the most specific arguments that are passed is called. So in Dylan, the following example works as expected: define class <window> (<object>) end; define class <application-window1> (<window>) end; define class <event> (<object>) end; define class <left-click-event> (<event>) end; define generic handle-event(window :: <window>, event :: <event>); // Methods look stand-alone but they are implicitly belong to the generic // function of the same name. define method handle-event(window :: <application-window1>, event :: <left-click-event>) // do something end; define method handle-event(window :: <window>, event :: <event>) // do something else end; let event :: <event> = make(<left-click-event>); let window :: <window> = make(<application-window1>); handle-event(window, event); Here the handle-event method called is the one that has the <application-window1> and <left-click-event> arguments. Or any other method that fits into the inheritance hierarchy. I believe this form of OO, as used by Dylan and CLOS, is easier to use than the C++/Java form of class based OO. Extension without modifying existing classes is easier, and multi-method dispatch is something you wonder how you managed to live without when you get used to it. Another language that uses multi-method dispatch is Cecil , and I'm sure there are others. If you are thinking of implementing OO ideas on top of Rebol, you might like to consider some of the alternative OO systems. Here's some links: Dylan: http://www.double.co.nz/dylan Cecil: http://www.cs.washington.edu/research/projects/cecil/www/cecil-home.html Common Lisp (CLOS): http://ww.telnet.net/cliki Please note that I include these links and the examples above not as advertisements for using other languages. I include them so you can get a feel for how different OO systems exist, possibly easier to use than standard class based OO, and how you might like to include some of the ideas in Rebol if you are looking to create an OO system for Rebol. Chris.

 [7/12] from: chrismorency:videotron:ca at: 9-Sep-2001 18:00


Hi, Although we have access to a great library of scripts through RT's (available under View and on their website), most of the understanding of Core or View usually goes through looking at script others built for specific reasons, copy and paste the code and refined them to our particular needs, or the current Core documentation and limited View documentation. AFAIK, we have yet to see completely re-usable libraries, which provides only frameworks and development-tools. Let's take for instance Object oriented programming under REBOL, we have yet to see a public framework/library that offers standard objects and objects-methods. For example, some people may have actually coded a Collection! class-object like I did, what about using Class! objects to build objects ? What about having all Class! objects having a new methods to build a new object based on that class, how about having type-of? to verify the type of an object and receive something more meaningful than type? myCollection == object! How about building an object framework that will allow inheritance instead of cloning ? How about a View framework which will simplify building layout through objects? What about multi-line edit box under view that will manager the slider for us without having to have it done the way we do actually ? These are some of the problems I have encountered in the past few weeks, and I have started working on, but actually, the task is big and I don't consider myself as a really technical programmer in that sense. I couldn't do it all by myself. What about building a SDK in Rebol for Rebol... I daily use Visual Age SmallTalk at the job and I have yet to see a better SDK environment. What if we could build a concurrent development environment in Rebol ? What about the object browser Etiennne was talking about... what about a Visual Debugger which will offer a stack ? etc. This can go on and on... but what I am suggesting is the following : RT has given us tools, let's use them to build other tools we can re-user afterwards for our own projects. I know that Rebol was not really meant for OOP, but one of the thing OOP is all about is : Reusability, not within a single project, but global, world-wide reusability for all developers. Why shouldn't we work on something like this ? My suggestion : let's build libraries that even the new rebolers will understand ! in order to make them more efficient... by simply adding like do http://www.reboltech.com/framework/object-library.r Maybe I'm wrong, maybe I didn't get the idea or I am an idealist, therefore flame me ;) but I would be interested in working with others on this... Best, Chris note : my rebol website for mobile programming is currently on hold... yep, my isp has blocked incoming request on port 80 because of code red ! and although the site is available through 8080, it wouldn't give me much good to go public at the moment.

 [8/12] from: petr:krenzelok:trz:cz at: 10-Sep-2001 7:07


'lo Christian, :-) Christian Morency wrote:
> Let's take for instance Object oriented programming under REBOL, we have yet > to see a public framework/library that offers standard objects and > objects-methods.
IIRC, Ladislav Mecir created methods.r some time ago? It allowed you to have classes, objects, methods, etc. IIRC ... I just wonder, if it is still available anywhere? :-) On the other hand - I programmed in CA Visual Objects. I read many papers on object orientation, and while I am not too good programmer, I sometimes don't fully understand all the fuss about object orientation and its advantages - hey, the result is some executable code, user doesn't care, so the only one question is - programmer's efficiency. With Rebol, you get nice space navigation, you have very dynamic binding on demand. So, if I understand things correctly, you have much wider freedom to define things exactly as they fit your solution. btw: as of Core 2.5, object creation functionality was slightly extended - although I never found practical reason to use it :-) http://www.rebol.com/docs/core25.html#section-11
> For example, some people may have actually coded a > Collection! class-object like I did, what about using Class! objects to
<<quoted lines omitted: 12>>
> What about building a SDK in Rebol for Rebol... I daily use Visual Age > SmallTalk at the job and I have yet to see a better SDK environment.
Would be nice to have. I just wonder what happened to Carl's Rebol/Author ....
> What if > we could build a concurrent development environment in Rebol ? What about > the object browser Etiennne was talking about...
Yes, style I miss most, is fast, nice tree-view ...
> what about a Visual > Debugger which will offer a stack ? etc.
Debugger ...would be helpfull ...
> This can go on and on... but what I am suggesting is the following : RT has > given us tools, let's use them to build other tools we can re-user > afterwards for our own projects. I know that Rebol was not really meant for > OOP, but one of the thing OOP is all about is : Reusability, not within a > single project, but global, world-wide reusability for all developers.
But reusability as you describe it, has very low in common with object orientation itself imo. The topic ran here several times already. The Rebol script header contains 'needs field, so the idea was that once you do %some-script.r, and its header contains Needs: [http://rlibrary.com/gfx/effects.r 1.2], it would look for it locally, and if not available, script would try to download it from the library ... Another usefull thing would be probably to extend help to work upon objects - to autocollect help info from it's functions, print list of words and their values, etc. What would I like to see maybe even more, - more dialects ... -pekr-

 [9/12] from: greggirwin:starband at: 10-Sep-2001 1:37


Hi Chris, I'm coming to REBOL from VB and I'm used to having an IDE myself. While there are certain things I would love to have in an IDE for building REBOL apps (like Intellisense and QuickInfo syntax help), and for helping me learn it as quickly as possible, I don't know if modeling REBOL tools after the things we're familiar with is the best approach. REBOL is revolutionary and I think, to take full advantage of what it can do, we need to focus on the end rather than the means. For example, we're used to having a way to ask an object what it is (typeof). If I know what kind of object it is, I know how to react, right? Well, that works if you know all the types of objects that you might be dealing with, but what if you don't? Imagine your REBOL script is an agent running around the internet. Will everyone you want to talk to be using the same type library? There will be times that we want to try to guarantee correctness to the n-th degree and tightly control things but what if we said "I want to talk to this guy so I ask if he speaks a dialect I know. If not, is there a mediator out there somewhere who can translate for us?" I don't care what kind of object he is. I only care if we can talk to each other. Maybe this comes full circle and dialects fill the position of IDL/ODL stuff but, wow, what a difference that would be IMO. I would love to help build some reusable libraries for REBOL but I don't know what the best approach might be due to my inexperience with it. So far I'm just working on some basic building blocks to get to know REBOL (stack, queue, dictionary, string manipulation functions). As I'm picking things to work on, I'm looking for those things that I really use all the time. REBOL has features built in which will eliminate a lot of the libraries I've written for myself over time. Rather than try to put a big OO layer on top of REBOL, I'd say "think small". What are *concrete* 3 things you rely on every day, or in every project? By concrete I mean avoid abstract concepts like inheritance. Reading ASCII files, mapping COBOL records, designing GUIs, one-off code generators, that kind of stuff. Just some thoughts (from my position of near ignorance <g>). --Gregg

 [10/12] from: lmecir:mbox:vol:cz at: 10-Sep-2001 12:34


Hi, Pekr wrote: ...snip...
> IIRC, Ladislav Mecir created methods.r some time ago? It allowed you to
have
> classes, objects, methods, etc. IIRC ... I just wonder, if it is still
available
> anywhere? :-)
...snip... I am not sure about the availability, but can put it to my Rebsite (http://www.sweb.cz/LMecir/index.r) in the case anyone is interested Ladislav

 [11/12] from: greggirwin:starband at: 15-Sep-2001 11:30


Hi Chris, I've been thinking about this some more and I thought I'd throw out some ideas to see if anything sticks. What if we start by creating some libraries. We should be able to get at least some small consensus on a reasonable taxonomy from the people here. The RT script library is categorized and provides lots of great examples in specific contexts but, for people just learning REBOL (like me), it can be quite time consuming to sift through the code in the examples to find the bits you need and extract them. I may be unusual but, as much as I like just grabbing something that works and using it, I really like to undertand the tool(s) I'm using. That means taking apart the RT examples and figuring out what each little piece does so I can extract and generalize the bits I need. I'm building up a collection of my own functions and I'll need to organize them somehow, so why not kill two birds with one stone.<g> What if we use contexts for namespacing to manage libs? For example, we could use contributors initials as the top level. rt /math /str /obj gsi /math /str /obj cm /math /str /gfx Alternately, you use the category names as the top level and then just include comments about the contrbutors, if so desired. A key will be simplcity in the naming. That is to say, making sure that using the standard library functions doesn't add so much prefixing that readability suffers. Using a single special character as a prefix, or suffix, might be less intrusive than a "-lib" suffix (as in the example below). *math math* math-lib *str str* str-lib *obj obj* obj-lib *gfx gfx* gfx-lib I don't know what the tradeoffs are between loading a large library of functions into the global space versus putting them in contexts. I.e. are we going to pollute the global space horribly or do we suffer a memory or performance penalty by using contexts? We could also (well, we meaning someone who knows what they're doing <g>) build a tool that would extract only the required definitions and combine them into a deployment file. That way you could develop with the whole library but then take a "snapshot" of the functions you use and put them all in a single file for distribution. Pros? Cons? I'm open to critiques and comments on all sides. I don't think we want to build a big, complex, unREBOLish beast but just a more granular library that people can use and learn from. --Gregg

 [12/12] from: chrismorency:videotron:ca at: 16-Sep-2001 1:32


Hi
> What if we start by creating some libraries. We should be able to get at > least some small consensus on a reasonable taxonomy from the people here.
<<quoted lines omitted: 3>>
> quite time consuming to sift through the code in the examples to find the > bits you need and extract them.
Exactly, currently all scripts are interresting, doing specific or general things, however we still have to look at other's script to dig the stuff and put it in our code (especially for view)... why can't we could simply linked an online library. For example, the scrolling function for text-area and scroll-bars, why this script is not within an add-on view library I could link... and it would work for my script and others ? without having me going in the RIM to get it out ?
> I may be unusual but, as much as I like just grabbing something that works > and using it, I really like to undertand the tool(s) I'm using. That means
<<quoted lines omitted: 4>>
> why not kill > two birds with one stone.<g>
I'm currently doing the same.
> What if we use contexts for namespacing to manage libs? For example, we > could use contributors initials as the top level.
<initial example snipped> I have take the habit of naming my script like this : cm-script-name.r so I know this is something I work on myself. When I take script from the library and change it for my own needs, I do the same but I still leave the author info... This is to remind me that this has been modified, but it's not mine ;)
> Alternately, you use the category names as the top level and then just > include comments about the contrbutors, if so desired. A key will be
<<quoted lines omitted: 7>>
> *obj obj* obj-lib > *gfx gfx* gfx-lib
Good idea ! Maybe RT would gladly make a Library folder, where we could put generic stuff that can be reused in other scripts directly... Those library shouldn't do anything on their own. They should be dialects, functions, objects, etc. Also, the script headers should list all of the global words which will be used for the script, so an author would knwo if there is any conflict with his own script... maybe we would need some kind of naming convention like you mention above...
> I don't know what the tradeoffs are between loading a large library of > functions into the global space versus putting them in contexts. > I.e. are we > going to pollute the global space horribly or do we suffer a > memory or performance penalty by using contexts?
I'm sure we should go with contexts and dialects, although I havent played with that yet... or Objects, which is the way I've taken so far because it makes sense for me (I can understand others would not be interested in OOP)
> We could also (well, we meaning someone who knows what they're doing <g>) > build a tool that would extract only the required definitions and combine > them into a deployment file. That way you could develop with the whole > library but then take a "snapshot" of the functions you use and > put them all > in a single file for distribution. Pros? Cons?
Good idea, I also think that libraries should be analyze first by a group of people (mailing list?) in order to check their quality, evaluate eventual modification to make them better and more readable to user. We can't afford to put snippets of codes with strange functions name and arguments that nobody will understand.
> I'm open to critiques and comments on all sides. I don't think we want to > build a big, complex, unREBOLish beast but just a more granular > library that people can use and learn from.
Exactly... Best, Chris

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