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 < [EMAIL PROTECTED] > wrote: From: Richard Gaskin [mailto: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Mon, 19 Jul 2004 01:15:20 -0700 Subject: Re: scriptsLimits K wrote:<br><br> > I must ask what those of us who enjoy OOP are supposed to do<br> > in the mean time? I like the idea of creating button/control<br> > that are used like Template/Visual Basic classes.<br><br>Don't use a procedural language? I'm not being cheeky, but if OOP is <br>more important than what Transcript offers there are plenty of true OOP <br>languages around.<br><br>But if Transcript still holds some appeal in spite of not being a formal <br>OOP implementation, there may be some satisfying solutions to provide <br>similar benefits within its current message-passing scheme.<br><br>I dug up your original post:<br> > I am working on a OOP library for 'RR' and I am fuzzy on a<br> > few 'RR' internals. I currently have a 'control' that<br> > represents a template class (each is self registering).<br><br>What does this "registration" entail?<br><br> > When the developer calls createInstance a clone of that<br> > control is created and 'the script' is modified to ac cept<br> > messages in the form of <instance name>.<method> at this<br> > time the script property is set and added to the backscripts.<br> > This does not seem to work in a stand-alone due to script<br> > limits any ideas on alternatives to this?<br><br>If you're adding class behavior scripts to instances you're not going <br>for much of an OOP benefit. :)<br><br>If the limitation is the number of backscripts (which presumably you're <br>using to hold the "class definition"), consider using libraries instead. <br> While you can have only 10 backscripts inserted into the message path <br>in a standalone, you can have up to 50 libraries. If you need more than <br>50 there's an argument to be made that you made have more subclasses <br>than may be truly necessary to get the job done.<br><br>On my Rev downloads page at <br><http://www.fourthworld.com/rev/downloads.html> is an old example of a <br>similar concept I called "libD'oh!" ("the poor man's OOPS" -- please <br>pardon the Simpsons pun, but it seemed appropriate for such a midly <br>interesting library of limited practical value).<br><br>That library is a very simple example of one way to simulate classes by <br>using a frontScript which traps system messages, checks the target for a <br>"Class" property, and then sends a message in the form <br>"<class>.<message>" (e.g., "myWidget.mouseUp"). If you include a <br>library with matching handler names it'll go well. You could include a <br>function in each library that returns a list of all such messages, so <br>your frontScript dispatcher would only bother send those that are supported.<br><br>The limitation that kept me from pursuing it is that such a <br>frontscript-based mechanism can only be used for system messages.<br><br>Better still might be to use property settings as triggers, since <br>getProp and setProp can be used quite flexibly for a wide range of such <br>things. There may be other useful tricks as well, depending on what' s <br>needed.<br><br>But most such solutions assume that your classes will be defined prior <br>to runtime. If you need to define classes on the fly (which OOP <br>languages support that?) I don't have much to offer there and will defer <br>to Dar as he comes up with some of the cleverest things sometimes. :)<br><br>If what you're looking for follows the more common aproach of having <br>behaviors defined during development and merely called during runtime, I <br>would be interested in seeing what we can come up with here to <br>facilitate your preferred workflow.<br><br>What does this app do?<br><br>-- <br> Richard Gaskin<br> Fourth World Media Corporation<br> ___________________________________________________<br> Rev tools and more: http://www.fourthworld.com/rev<br><br>_______________________________________________<br>use-revolution mailing list<br>[EMAIL PROTECTED]<br>http://lists.runrev.com/mailman/listinfo/use-revolution<br> _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
