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