> 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
Brent Dax wrote:
>On the other hand, it could stop some of the really stupid uses for
>inheritance I've seen. The dumbest one was in high school Advanced
>Placement's C++ classes--the queue and stack classes inherited from the
>array class!
Oh? How could "final classes" prevent such a travest
On Tue, 28 Aug 2001, Sam Tregar wrote:
> Well, there's the Perl 5 reference counting solution. In normal cases
> DESTROY is called as soon as it can be. Of course we're all anxious to
> get into the leaky GC boat with Java and C# because we've heard it's
> faster. I wonder how fast it is when
This arrived as part of a mailing list that I suppose I opted into
at some point:
==
More ++, Less C
Standard template libraries, abstract classes and multiparadigm programming
are keys to
high-performance
==
"Too much C++ code is just C.
Michael G Schwern wrote:
> If you *really* wanted to write an optimized redirector, you'd
> have the redirector eliminate itself.
>
> sub foo {
> my $method = $_[0]->{"_foo"} || $_[0]->can("_foo");
> {
> no warnings 'redefine';
> *foo = $method;
> }
> goto &$meth
Michael G Schwern wrote:
> The idea that a class is either 'perfect' or 'complete' has to be the
> silliest, most arrogant thing I've ever heard!
So, subsequent refinements have to use a "has-a"
instead of an "is-a" relation in re: objects of the "final" class.
Maybe the inclusion of this fe
http://www.jwz.org/doc/java.html includes the following gripe
about Java:
> I sure miss multi-dispatch. (The CLOS notion of doing
> method lookup based on the types of all of the arguments,
> rather than just on the type of the implicit zero'th
> argument, this).
CLOS is of course the Commo
> > I sure miss multi-dispatch.
http://dev.perl.org/rfc/256.html
Damian
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
On Wed, Aug 29, 2001 at 10:49:25PM -0700, Hong Zhang wrote:
> What is the need for CLOS? Are we trying to build a kitchen
> sink here?
Umm, I think you mean "What's the need for multiple dispatch?"
Currently, if I want to write a method that does this:
my $name = $foo->name;
$foo->name(
Schwern explained:
> # Following RFC 256
> sub name (Foo $self) : multi {
> return $self->{name};
> }
>
> sub name (Foo $self, STRING $name) : multi {
> $self->{name} = $name;
> return $self->{name};
> }
>
> which is q
> What is the need for CLOS? Are we trying to build a kitchen
> sink here?
To echo Michael, CLOS != multiple dispatch.
> http://dev.perl.org/rfc/256.html
"The usefulness of multiple dispatch depends on how intelligently the
dispatcher decides which variant of a multimethod is "nearest" to a
giv
12 matches
Mail list logo
