Rev v. Java - How to structure academic project? (kinda long)
janschenkel at yahoo.com
Wed Oct 9 03:52:01 CDT 2002
--- Jim Witte <jswitte at bloomington.in.us> wrote:
> I see Rev (Hypercard originally) as being a more
> "concrete" example
> of OO than Java is. In Java, you create an abstract
> class to
> *describe* a button and what it's actions are, then
> you instantiate it
> on a "canvas" (which you also have to instantiate)
> and then you run the
> program to get the interface. In Rev, you simply
> create the button.
> In Java, there are actions (handlers/instance
> methods) linked to button
> objects, but they seem to me to be far removed from
> the "actual button"
> you see on the screen - they are in the source file.
> Jim Witte
Personally I feel that the choice between RunRev and
Java (an any programming language/environment for that
matter) depends on your requirements.
If you need support for your program on a specific
platform, you could be out of luck: there's no RunRev
for PalmOS, for instance.
Or if your project requires that you setup a
multi-threaded system (never mind the headaches that
come with that) you have no choice but to go for Java.
Yes, you can come close with RunRev and the message
queue (send "doIt" && tParam1 & comma & tParam2 to me
in 10 milliseconds) but when a piece of code is busy,
no other piece of code can run.
If you don't require these extras, RunRev is
definitely your choice (or Flash/Shockwave if it has
to run inside a browser, but web-apps versus net-apps,
that's a whole different discussion).
It all depends on your requirements...
At any rate, the thing I really wanted to discuss is
that RunRev is _not_ object-oriented but object-based,
whereas Java is a fully object-oriented language (and
even found a solution to the multiple inheritance
nightmare of C++).
RunRev has encapsulation, but there is no real
inheritance. RunRev has a message hierarchy and a
message queue, but all in all xCard environments have
merely taken a series of very good ideas from OOP.
Example: if you want a field that only accepts numeric
input, here's what you would do:
1) Java: create a new subclass JNumericField of
JTextField (i don't have my books at hand right now,
so it could be a different class) and make it so that
it only accepts numeric input. Then, whenever you need
a numeric field, you make an instance of that class.
2) RunRev: look at the use-revolution archive and copy
the script I posted a week or so ago ;-)
But the difference come in maintenance: suppose
there's something wrong with your code in a special
In Java, you fix the JNumericField class, and it's
fixed everywhere. In RunRev, you have to go through
all your numeric fields and fix it repeatedly.
Granted, you can do a lot with the frontScript and
backScript mechanisms to alleviate these problems, but
it's a different metaphor -- there's no parentScript
property so you can say: this button does everything
that button does, except for this handler.
MetaCard has promised to add more OOP-features to the
engine, but there's no real explanation of what those
In Java you can add classes at will. Is there a type
of object or control you need that isn't there? You
can easily add it yourself -- think of all the
FTPConnection classes that appeared on the web when it
wasn't included in the network package.
In RunRev you have a fixed set of controls, admittedly
a very flexible set but there is for instance no real
table control (you can emulate one but it's not a true
table control at heart) and no chance of adding it at
the core level nor through externals.
It is true that you can go a long way with all that
RunRev has to offer, but when you have certain needs
the xCard metaphor might prove a cage -- a golden cage
but still a cage.
Just my 2 euro-cents...
"As we grow older, we grow both wiser and more foolish
at the same time." (La Rochefoucauld)
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
More information about the use-livecode