Now think about this for a minute. If your standalone were unlocked, yes, someone might create a competing IDE. But even if they just used your standalone to create their own software, that is one less copy that Runtime would sell. You and I, as developers, are staking our future on this technology. We should *want* Runtime to guard their product, sell lots of copies, and have a huge customer base so they will survive to be there for us. Why would anyone pay for a developer copy when any old standalone with a message box was fully functional?
The script limitation is the one, single, sole, solitary, and only protection that Runtime has.
All true but how easy is it to use the engine of a standalone to couple it with full development GUI to produce new products? Is message box really fully functional in standalones? If so, I rather have no message box than do limit. I also think that while distributing an unlocked engine could lead to problems you describe, it should be possible to couple the engine to a specific standalone, for example by requiring the stacks in the standalone to pass the license key with certain calls. Such an approach would allow us to realize the unfullfilled promise of being able to distribute any! MC/Rev-based standalone without it being crippled by this restriction.
And I agree with Alex that this should be clearly spelled out. I have actually found about this restriction when producing a test version of a standalone program (see below) -- after I paid for the license. I was quite upset. Fortunately, that specific program was not the only reason for me to buy the dev environment.
There's also the issue of abstract versus reality. In the 16 or more years in which I have been writing x-talk scripts, I can honestly say I have never once needed an 11-line "value" function. I can't imagine the convoluted script that would require something like that. I can't even imagine a script where the syntax would work out. I suppose someone might want to plop a whole field's worth of script into a "do" command, but not only is that rarely necessary, there are ways to break the code up if it really is required. Only it hardly ever is. I've never needed a "do" statement that long.
In practice, I think you will find the script limitation to be a completely minor inconvenience, worthy of almost no consideration at all, except as a great big chunk of insurance against the future for all of us.
Well, this may be true for most people but it can be a show stopper for some. Consider a scientific application that involves modelling or function fitting. I have written such a program some years ago (sold as shareware) and would love to recreate it with MC/Rev (users still ask for it but the old code stopped working with OS 8). It requires users entering complex math functions that program matches to the provided set of experimental data, calculating statistical fit and producing graphical output. It would be trivial to run it through "do", but the 10-line limit is a killer. The only alternative I see is to write my own interpreter/compiler in MetaTalk but that ain't so trivial and slows things down. Of course, another alternative is to have each user buy their own copy of MC or Rev but that would be akin to asking users of programs written in C to buy CodeWarrior (although I am sure that MC/Rev folks would love it).
Robert Brenstein _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
