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
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
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
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
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: 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->();
>
>
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 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
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
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.
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!
>
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:
> 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
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
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 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
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 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, 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 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
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
> 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'
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
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, 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
> 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-
# -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
27 matches
Mail list logo
