James Mastros [EMAIL PROTECTED] wrote:
The idea is [for Larry] to declare "no, it isn't". Otherwise, you have to
do refcounting (or somthing like it) for DESTROY to get called at the right
time if the class (or any superclass) has an AUTOLOAD, which is expensive.
I'm coming in halfway
James Mastros [EMAIL PROTECTED] wrote:
[snip about DESTORY predictablity not being neccessary]
You're probably right about that, Branden. Quite nice, but not neccessary.
Hmm, I'd have to say that predictability is very, *very* nice,
and we shouldnt ditch it unless we *really* have to.
[ lots
James Mastros [EMAIL PROTECTED] writes:
Why can't we change the meaning of time() slightly without changing to a
different function name? Yes, it will silently break some existing code,
but that's OK -- remember, 90% with traslation, 75% without. being in that
middle 15% isn't a bad thing.
"Branden" [EMAIL PROTECTED] wrote:
Well, mandatory locking is something we should definetly NOT have in Perl6.
Most of perl's code today is not threaded, and I believe much of it will
continue to be this way. The pseudo-fork thread behaviour that is being
proposed also makes this ok. Even if
"Branden" [EMAIL PROTECTED] wrote:
The thing with mandatory locks per variable, is that as long as you only
want to access _that_ variable, it's ok, but if you want to make several
uses of several variables and want to do it all at once, you've got a
problem.
[ big snip ]
Sorry, I
Jeanna FOx [EMAIL PROTECTED] wrote:
Everybody seems to be missing the fact that jwz bitching about Java's
"32 bit non-object ints" means that at least he thinks they could be
salvaged. What would he think of Perl's "224 bit non-object ints"?!
Don't get smug because Perl can iterate over an
Perhaps you meant that Perl 6 is going to have homogeneous arrays, in
which case an array of ints would keep 32 bits (per value) of int data in
the array and auto-generate the extra flags and stuff when a value is
extracted from the array. That's possible, but it's a special case of small
