[REBOL] Re: Rebol Framework suggestion
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