I don't understand what you mean by this. Your extensible stacks are your
products. ("Product" does not mean "commercial product", nor is it
restricted to standalone applications.) It sounds from your description
like your products would in fact impact the products you make, so my
suggestion of discussing this with Kevin is still my advice.
This is missing the point. The principle advantage of metacard/RR is that it provides for dynamic programming *and* it does so in a cross-platform way. I have and use c, c++ compilers, Futurebasic, RealBasic, and so on, but for different purposes. None of these other programming environments is *dynamic*. Scott Raney's important statement that metacard is written in metacard was not to make the point that, as with c or Basic or Fortran compilers one could write a c, or Basic or Fortran compiler with it, but rather that the system is bootstrapped. The possibility of producing ``standalones'' in hypercard and metacard has unfortunately helped disguise this fact to the point where many (Shari C is a fine example, here, and more power to her) think of metacard/RR as just another IDE with fine cross-platform capabilities. That it no doubt is, but that's not what makes it either unique or important: it is the possibility for dynamic programming that the engine provides, as with hypercard. Limiting script length and ``do'' to non-licensed RR users means that *only* licensed RR users of the stacks I produce can can partake of the dynamic nature. Thus, rather being an essential part of metacard/RR, this dynamism becomes a feature *only* licensed users (developers?) can use, but can't retain in the stacks they produce. By all means, strip it out of standalones if need be, but leave it as an essential feature of stacks.
For those who remember them, think of the completely different experience one has programming in and using TILs (threaded interpretative languages) such as APL, and forth: as with hypercard, programming is not distinct from using; they are seamlessly integrated. *That* is what we will be losing by these limits. For those who use metacard/RR to produce applications without those dynamic capabilities, I can understand why they don't feel these limits amount to much. But for some, at least me, it is the dynamism that is my whole reason for using metacard, recommending it to students, and so on.
John R. Vokey
_______________________________________________ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
