> 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
> Uri Guttman
> > we are planning automatic over/underflow to bigfloat. so there is no
> > need for traps. they could be provided at the time of the
> > conversion to big*.
>
> OK. But will Perl support signaling and non-signaling NANs?
I don't think we should go for automatic overflow/underf
> >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
> >assumptio
> 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
> 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;
> }
>
>
What is the need for CLOS? Are we trying to build a kitchen
sink here?
Hong
> -Original Message-
> From: David L. Nicol [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 29, 2001 9:43 PM
> To: [EMAIL PROTECTED]
> Subject: CLOS multiple dispatch
>
>
> http://www.jwz.org/doc/java.htm
> 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
> I don't think speed is where the interest is coming from. GC should fix
> common memory problems, such as the nasty circular references issue that
has
> caught all of us at some time.
Normally, GC is more efficient than ref count, since you will have many
advanced gc algorith to choose and don'
> 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 strongly-
> 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. (Ex
>I tought about a posibility to access a HASH in way that the VALUES can
also
>be used like KEYS...i.e in perl6 I will say this :
>
>%hash{key} = value;
>
>I want to say also :
>
>{value}hash% = key;
Please forget about it. It is just syntactic sugar for yourself. The hash
mapping
is m-to-1, th
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
> >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 o
> 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
> >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.
>
Are we over-optimizing? The Perl is just an interpreter language.
Who really needs this kind of optimization for Perl? Even C does
not provide this feature. Though Pascal/Ada have distinctions
like function/procedure, it does not make them any faster than C.
Just given its ugly name, I hate to se
16 matches
Mail list logo
