scriptsLimits

[Richard Gaskin]

K wrote:

 > I must ask what those of us who enjoy OOP are supposed to do
 > in the mean time? I like the idea of creating button/control
 > that are used like Template/Visual Basic classes.

Don't use a procedural language?  I'm not being cheeky, but if OOP is 
more important than what Transcript offers there are plenty of true OOP 
languages around.

But if Transcript still holds some appeal in spite of not being a formal 
OOP implementation, there may be some satisfying solutions to provide 
similar benefits within its current message-passing scheme.

I dug up your original post:
 > I am working on a OOP library for 'RR' and I am fuzzy on a
 > few 'RR' internals.  I currently have a 'control' that
 > represents a template class (each is self registering).

What does this "registration" entail?

 > When the developer calls createInstance a clone of that
 > control is created and 'the script' is modified to accept
 > messages in the form of <instance name>.<method> at this
 > time the script property is set and added to the backscripts.
 > This does not seem to work in a stand-alone due to script
 > limits any ideas on alternatives to this?

If you're adding class behavior scripts to instances you're not going 
for much of an OOP benefit. :)

If the limitation is the number of backscripts (which presumably you're 
using to hold the "class definition"), consider using libraries instead. 
  While you can have only 10 backscripts inserted into the message path 
in a standalone, you can have up to 50 libraries.  If you need more than 
50 there's an argument to be made that you made have more subclasses 
than may be truly necessary to get the job done.

On my Rev downloads page at 
<http://www.fourthworld.com/rev/downloads.html> is an old example of a 
similar concept I called "libD'oh!" ("the poor man's OOPS" -- please 
pardon the Simpsons pun, but it seemed appropriate for such a midly 
interesting library of limited practical value).

That library is a very simple example of one way to simulate classes by 
using a frontScript which traps system messages, checks the target for a 
"Class" property, and then sends a message in the form 
"<class>.<message>" (e.g., "myWidget.mouseUp").  If you include a 
library with matching handler names it'll go well.  You could include a 
function in each library that returns a list of all such messages, so 
your frontScript dispatcher would only bother send those that are supported.

The limitation that kept me from pursuing it is that such a 
frontscript-based mechanism can only be used for system messages.

Better still might be to use property settings as triggers, since 
getProp and setProp can be used quite flexibly for a wide range of such 
things.  There may be other useful tricks as well, depending on what's 
needed.

But most such solutions assume that your classes will be defined prior 
to runtime.  If you need to define classes on the fly (which OOP 
languages support that?) I don't have much to offer there and will defer 
to Dar as he comes up with some of the cleverest things sometimes. :)

If what you're looking for follows the more common aproach of having 
behaviors defined during development and merely called during runtime, I 
would be interested in seeing what we can come up with here to 
facilitate your preferred workflow.

What does this app do?

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________
  Rev tools and more:  http://www.fourthworld.com/rev