On Feb 26, 2006, at 10:08 AM, Mark Wieder wrote:
That's sort of what I'm doing now. Inheritance is actually fairly
easy. The hard part is that scripts are associated with screen objects
- you can't have objects that don't have screen representations.
For instance, I have a linked-list class that I use as a base class
for other classes. But there's no way to inherit the script without
making both the base and sub classes scripts of buttons or something
else. And adjusting front- and back- scripts accordingly. And paying
*very* careful attention to the message path.
Agreed. What I had envisioned would do nothing to implement abstract
classes/objects, except inasmuch as you could have as many hidden
objects as you like. See below:
On Feb 26, 2006, at 10:39 AM, Dan Shafer wrote:
Interesting implementation. My guess is that it's not going to be very
efficient in execution, but perhaps we just throw more hardware at it
as someone else has suggested.
The real problem for me is that it's not possible to create subclasses
of components. The recently departed Xavier spent a lot of years
trying to get that to work and although he came very close to a decent
simulation, actually implementing objects in a language not designed
for them leads to things like C++, which was procedural C with objects
glued clumsily to its side.
Subclassing components is what I had in mind. For those who weren't
around the last time this came up ;-) the issue is roughly this
(anyone who disagrees feel free to jump in):
=====================================================================
In Revolution, the object hierarchy is container based. A button (or
any control) can inherit behavior from any group that contains it,
from the card it is on, from the stack it is in, or from the
mainstack it is part of. So, for example, it would be easy to put
together a set of radio buttons labeled "red," "green," and "blue,"
and display an answer dialog with which button is clicked. To do
this, group the buttons, and put in the group script:
on mouseUp
answer the short name of the target
end mouseUp
Since all the radio buttons are in the group (and only the radio
buttons) this works.
But suppose you wanted another set of buttons on another card to do
the same thing? The standard method of accomplishing this would be to
group those buttons as well, and put the exact same script in their
group.
This is a Bad Thing. If you later decide that the answer dialog
should be a warning dialog, you have to remember that the routine is
in two places, and change them both. For two groups it's not a big
deal, but what if you have ten such groups, or a hundred?
The alternative is to go to the point where the buttons share an
ancestor: the stack script. But there are many buttons and other
controls that _don't_ need to display this dialog. So you end up with
something like this in the stack script:
on mouseUp
if the uDisplayName of the target is true then
answer the short name of the target
else if the uSomethingElse of the target is true then
-- do something else
else -- you get the idea -- it's ugly
There may be a better way to do this outside of traditional object
oriented techniques. I haven't ever tried to implement something like
this before.
The Object Oriented way to do this is to define a new group type:
alertGroup, say. In the definition of the alertGroup, you include the
original mouseUp handler. Then any time you need a group that has
this behavior you declare it to be an alertGroup (instead of a
generic group). In every way it acts like a normal group, but when a
control in it is clicked, it displays a dialog with the name of the
control. If you need to make it a warning dialog, change the class
definition and the behavior everywhere changes. It's really much the
same as the non-oo solution above, but without you the coder having
to do all the work.
==================================================================
All of that said, I believe I have object-oriented code in this
limited sense working. If I do say so myself, it's simple, has low
overhead, consists of less than 100 lines of code, and might be
completely useless ;-)
Right now it supports classes but no inheritance. I should have that
complete in a few minutes, at which point I'll upload version .1
regards,
Geoff
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
