Who really needs this kind of optimization for Perl?
I do. Lots of people with web apps do. Pretty much anyone with a large or
long-running perl program does.
I have to say that I agree to disagree. Since it has been so controversal,
I just don't think this optimization is a good one.
C
if we have a proper core event loop as dan and i want, multiple timers
will be part of that. and that will mean we can have timed out
operations without the mess of eval/die (or whatever 6 will have for
that).
Event loop will be great for many applications. We probably need
a better way to
There is no need to store pending signals. It will be impossible
to achieve in a multi-threaded perl runtime.
No, it won't be that tough to get multiple pending signals for a thread.
Not real Unix signals, perhaps, but what look like them, more or less.
If
several alarms time out
I don't think object inheritence has any significant advantage.
Since it is not widely used and understood, we should not use it
in Perl, period.
Its functionality can be achieved by many different ways. The
anonymous class is one of them. Personally I prefer using mixin.
The mixin is similar
On Tue, Aug 28, 2001 at 09:13:25AM -0400, Michael G Schwern wrote:
As the pendulum swings in the other direction you get
mind-bogglingly
silly things like finalize which I just learned of today.
What's so silly about finalize? It's pretty much identical to Perl's
DESTROY. (Except
Sorry, I ment final. final classes and methods. The idea that you
can prevent someone from subclassing your class or overriding your
methods. I've seen things that hinder reuse, but this is the first
time I've seen one that violently blocks reuse!
final is only useful for
You still need to malloc() your memory; however I realize that the
allocator can be *really* fast here. But still, you give a lot of the
gain back during the mark-and-sweep phase, especially if you also
move/compact the memory.
As you said, the allocator can be really fast. Most advanced gc
For example, here is an event handler for a GUI:
sub handle (Window $w, Event $e) : multi {
log(Unknown event $($e-desc) called on window
$($w-name));
}
sub handle (Window $w, CloseEvent $e) : multi {
$w-close;
}
sub handle
Because multimethods are inherently an OO technique.
You can say so, but I am not buying it very much.
It doesn't. The multimethod consists of those variants that are currently
loaded.
How do you define the currently loaded? If things are lazy loaded, the stuff
you expect has been
The only good justification I've heard for final is as a directive
for optimization. If you declare a variable to be of a final type, then
the compiler (JIT, or whatever) can resolve method dispatch at
compile-time. If it is not final, then the compiler can make no such
assumption because
Should we be allowed to use _ to group numbers, now that _ is concat?
If not _, then what? (if anything?)
Sure. In Perl 5, we have 123.456 and a . b, but in Perl 6, we will have
123_456 and 123 _ 456. People have to put space around '_' anway.
Hong
11 matches
Mail list logo
