object scripts

[Geoff Canyon]

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