On Tue, 28 Aug 2001 19:04:20 -0700, Hong Zhang <[EMAIL PROTECTED]>
wrote:
>Normally, GC is more efficient than ref count, since you will have many
>advanced gc algorith to choose and don't have to pay malloc overhead.
You still need to malloc() your memory; however I realize that the
allocator c
On Tue, 28 Aug 2001 18:35:34 -0700, Damien Neil <[EMAIL PROTECTED]> wrote:
>On Tue, Aug 28, 2001 at 09:07:03PM -0400, 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
> 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'
Sam Tregar wrote:
> On Wed, 29 Aug 2001, Jeremy Howard wrote:
>
> > The answer used in .NET is to have a dispose() method (which is not a
> > special name--just an informal standard) that the class user calls
manually
> > to clean up resources. It's not an ideal solution but there doesn't seem
to
On Tue, Aug 28, 2001 at 09:07:03PM -0400, 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
On Tue, 28 Aug 2001 21:07:03 -0400 (EDT), Sam Tregar <[EMAIL PROTECTED]>
wrote:
>On Wed, 29 Aug 2001, Jeremy Howard wrote:
>
>> The answer used in .NET is to have a dispose() method (which is not a
>> special name--just an informal standard) that the class user calls manually
>> to clean up resou
On Tue, Aug 28, 2001 at 05:23:46PM -0700, David Whipp wrote:
> 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 no
On Wed, 29 Aug 2001, Jeremy Howard wrote:
> The answer used in .NET is to have a dispose() method (which is not a
> special name--just an informal standard) that the class user calls manually
> to clean up resources. It's not an ideal solution but there doesn't seem to
> be many other practical o
Hong Zhang wrote:
> Most of finalization is used to deal with external resource, such as open
> file, socket, window. You don't really want to depend on finalization,
> since it is very likely run out of default file descriptor limit before
> the finalization kicks in. The rule of thumb is to let
On Tue, Aug 28, 2001 at 05:22:01PM -0700, Brent Dax wrote:
> # 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
> They list two reasons to make your class final. One is security
> (which might actually be valid, but I doubt it will hold up to
> determined attack), the other though...
>
> You may also wish to declare a class as final for object-oriented
> design reasons. You may think that your cla
# -Original Message-
# From: Michael G Schwern [mailto:[EMAIL PROTECTED]]
# Sent: Tuesday, August 28, 2001 4:35 PM
# To: [EMAIL PROTECTED]
# Subject: Re: Expunge implicit @_ passing
#
#
# On Tue, Aug 28, 2001 at 10:47:35AM -0700, Damien Neil wrote:
# > On Tue, Aug 28, 2001 at 09:13:25AM -0
> 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 10:47:35AM -0700, Damien Neil wrote:
> 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 final
> 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
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 that Java'
On Sun, 26 Aug 2001, Nathan Torkington wrote:
> Simon Cozens writes:
> > I was using .pas and .pac. Gotta think about 8.3ness, unfortunately.
>
> .pas is generally Pascal.
>
> I also think it's important we choose extensions based around their
> humour potential. With that in mind, I propose:
From: Ken Fox [mailto:[EMAIL PROTECTED]]
>
> > You forgot the other example that someone raised:
> >
> > { my $x = 'X'; *h = sub { $H = sub {pr $h} }}
> > h(); $H->();
> >
> > Which prints:
> >
> > Z
>
> Did you mean this?
>
> { my $z = 'Z'; *h = sub { $H = sub {pr $z} }}
> h(); $H->();
>
>
Garrett Goebel wrote:
> From: Dave Mitchell [mailto:[EMAIL PROTECTED]]
> > Okay, to humour me for a mo', what should the following 2 examples
> > output if Perl were doing the "right" thing?
> >
> > sub pr { print $_[0] || 'undef', "\n" }
> >
> > { my $x = 'X'; sub f { $F = sub {pr $x} }}
> > f();
From: Dave Mitchell [mailto:[EMAIL PROTECTED]]
> Ken Fox <[EMAIL PROTECTED]> wrote:
>
> > You're speaking in Perl implementation terms. I've already told you
> > that if Perl acts the way you say it does, then Perl has buggy
> > closures. You don't need to explain a bug to know that one exists!
>
Michael G Schwern wrote:
> On Mon, Aug 27, 2001 at 10:58:00AM -0400, John Porter wrote:
> > You can, with C< goto &$foo; >.
> > Problem is, it's *slower* (in p5 anyway) than the plain sub call.
>
> By only 10%. Let's keep things in proportion here.
O.k., thank you for supplying the proportion.
Ken Fox <[EMAIL PROTECTED]> wrote:
> You really need to learn what a closure is. There's a very nice book
> called "Structure and Interpretation of Computer Programs" that can
> give you a deep understanding. **
Quite possibly I do. Anyway, I've now got the book on order :-)
> You're speaking in
On Tue, Aug 28, 2001 at 09:10:40AM -0400, Ken Fox wrote:
> One of the cool things about Perl's OO system is that it lets
> us invent new type systems. This IMHO is its greatest strength.
> Perhaps this is also why some OO people hate Perl's OO?
Yes, this sort of thing FRIGHTENS THE HELL out of no
Michael G Schwern wrote:
> If you *really* wanted to write an optimized redirector, you'd
> have the redirector eliminate itself.
That's not always appropriate. In my frame system, an instance
can over-ride its class method. An instance can also remove the
over-ride and return to using the class
Dave Mitchell wrote:
> The whole point is that closed variables *aren't* 'just local variables'.
> The inner $x's in the following 2 lines are vastly different:
>
> sub foo { my $x= ... { $x } }
> sub foo { my $x= ... sub { $x } }
You really need to learn what a closure is. There's a
Ken Fox <[EMAIL PROTECTED]> wrote:
> We must be very careful not to confuse "closure" with "Perl's
> current implementation of closure". You've stumbled onto a bug in
> Perl, not discovered a feature of closures. Perl's "closures"
> were horribly buggy until release 5.004. (Thanks Chip!)
Er, no i
Kirrily 'Skud' Robert [mailto:[EMAIL PROTECTED]] said:
>
> My main purpose with perlmodstyle was to give us a starting
> point for a Perl 6 style guide, in time for the Great Rewrite
> that's likely to happen with most of CPAN.
>
I have some raw material that may be useful (and I do mean raw).
O
27 matches
Mail list logo
