chromatic wrote:
The thinking at the last design meeting was that you'd explicitly say
Consider this class closed; I won't muck with it in this application
at compile time if you need the extra optimization in a particular
application.
In Dylan, this is called a sealed class. It tells the
--- Andy Wardley [EMAIL PROTECTED] wrote:
chromatic wrote:
The thinking at the last design meeting was that you'd explicitly
say
Consider this class closed; I won't muck with it in this
application
at compile time if you need the extra optimization in a particular
application.
In
On Thursday, September 18, 2003, at 07:49 AM, Austin Hastings wrote:
Sounds like a potential keyword, or perhaps a ubiquitous method, or
both. But how to differentiate sealed under optimization versus
sealed under inheritance?
I don't understand the question.
The point is not for module authors
--- chromatic [EMAIL PROTECTED] wrote:
On Thursday, September 18, 2003, at 07:49 AM, Austin Hastings wrote:
Sounds like a potential keyword, or perhaps a ubiquitous method, or
both. But how to differentiate sealed under optimization versus
sealed under inheritance?
I don't understand
On Thursday, September 18, 2003, at 12:33 PM, Gordon Henriksen wrote:
Ah, shouldn't optimization be automatic? Much preferrable to provide
opt-out optimizations instead of opt-in optimizations.
No. That's why I tend to opt-out of writing in C and opt-in to writing
Perl.
Perl (all versions) and
