scriptsLimits

Mon Jul 19 05:21:34 EDT 2004

Honestly, when I found Revolution I was looking for a OOP, multi-platform, RAD language.  

I was not impressed by the design or implememtation of the laguage and I have seen better TIL/Interpreter implementations.  However, Revolution met my multi-platform and RAD requirements with little effort. I figured I could simply write a vtbl based OOP framework (since I have done it several times) to satisify my OOP requirements. I believe at this time I was incorrect.  It seems for a reason (that I am not privy to) the creators of RR hide/remove the constucts to extend the language (even in development mode).  Anyway I enjoy Revolution but I do not believe it suitable at this time for large multi-developer/multi-platform applications.  

P.S. 
My search still continues for the language that will fit all my requirements.  I still believe that Runtime will can make RR a contender in the Visual Basic, Delphi, Java arena.  However, it is my firm belief that this will not happen until it has further OOP capilities and a simple native call API.  The two features RR does not have that made Visual Basic 6 the force it is today.

K

-==-=-=-=-=-=-==-=-=-=-=-=-=-=-==-=-=-=-=-=-
Disclaimer:

Any resemblance between the above views and those of my
employer, my terminal, or the view out my window are purely
coincidental. 
Any resemblance between the above and my own views is non-deterministic.

 The question of the existence of views in the absence of anyone to hold
them
is left as an exercise for the reader. The question of the existence of
the reader
 is left as an exercise for the second god coefficient. 
(A discussion of non-orthogonal, non-integral polytheism is beyond the
scope of this article.)

 --- On Mon 07/19, Richard Gaskin < ambassador at fourthworld.com > wrote:
From: Richard Gaskin [mailto: ambassador at fourthworld.com]
To: use-revolution at lists.runrev.com
Date: Mon, 19 Jul 2004 01:15:20 -0700
Subject: Re: scriptsLimits

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 _______________________________________________ use-revolution mailing list use-revolution at lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!