RE: Perl 6 modules plan
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). Off and on for the last few months, I've been compiling notes on "Perl for Enterprise Development." Topics range from style, formatting, and naming conventions, all the way to team structure, culture, and software engineering principles from a Perl perspective. I originally planned to do a couple of things with this material: - Create a developers' guide to be used within my own organization, to help ensure the success of Perl-related projects. - Educate the powers-that-be in the company I work for that Perl is a reasonable choice for the development of maintainable, scalable, reliable, [insert desirable trait here] systems, despite what they may have heard otherwise. However, in light of the recent style and SDK discussions here and on P5P, I thought it might prove useful to the community at large. Most of this stuff isn't new, of course. I was happy to see that there's a lot of overlap between my random scribblings and perlmodstyle, for example. Stylistic issues owe a lot to the perlstyle manpage, the Camel book, and TomC's "Perl Style" talk. Much of it comes from staring at my own Perl code and trying to figure out what's good and what's not. The team dynamics / culture / pragmatism aspects are the result of spending a lot of my life developing software, and knowing what I like and what I don't like about the experience. Some things to remember: - This is a list of ideas, not a finished guide. The items are discussion points, memory-joggers, and questions to myself, and they shift gleefully among first, second, and third-person viewpoints (whee, what fun). - It's not done. The categories are ad hoc, items are in only the vaguest order, and many areas are missing or woefully under-represented. - It's written from a Perl 5 perspective, not Perl 6. - It's about large projects with multiple programmers or teams of programmers. I'm not advocating the "one true way" to do anything. TMTOWTDI and all that. - It wasn't originally meant for public consumption. If something doesn't make sense, ask me what I meant. I might even remember the answer. So if you're still interested after all the caveats, here it is. Tear it apart. :) --Bill === Perl for Enterprise Development === -- PHILOSOPHY -- Main idea: Many people consider Perl the ultimate tool for individual programmer productivity and creativity. Despite its detractors, Perl has proven fantastically well-suited for this role -- but often at the expense of another role that it is also qualified to fill. Perl is an excellent language for large-scale system development, and, properly used, extremely adept at bestowing the same creative, productive boon to enterprise projects that it has done so successfully for individuals. Pick your battles. Choosing to develop large systems in Perl *will* be controversial, no matter how often it's been successful in the past, so be sure to position the language choice appropriately. The reputation of the Perl language and community is muddy enough already without a failed multi-million-dollar project around our collective neck. Respect the developers. Often, methodologies (either consciously or otherwise) paint the actual builders of a system -- the programmers -- as uncouth rabble that must be tolerated because they -- tsk, tsk -- are so gauche, so blue-collar, that they (horrors) write code and (gasp) make the system *work*. *Don't do this* and don't allow it to be done in your organization. Allow Perl to work for you. The goal of this guide is not to turn Perl into Java or Python or C++, but to show how Perl can be used as an effective tool for team development and large system creation, and *still be Perl*. While it's certainly possible to write Perl that looks like Java, you're probably using Perl because it affords a different approach and a different philosophy to solving problems. Don't consign that philosophy to the scrap heap just because the problem is bigger. Be aware of the unique advantages that Perl brings. Many of the strictures of other methodologies exist because it is so *hard* to do anything with other languages. Taking a rigid, methodical approach is the only way to ensure, or at least encourage, timely, reliable results. Perl is different. In the time it might take to perfect one particular version of a C++ program, the Perl programmer can try ten different approaches, select the best one, and move on. This is the form of TMTOWTDI that we don't often celebrate -- that it can be used as a means to findin
Re: explicitly declare closures???
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 its not a bug - or at least Gurusamy didnt think so.
> Closed variables are just local variables. There's nothing special
> about refering to a variable from an inner scope. You don't want
> to write
>
> sub foo {
> my $x;
>
> if (...) { my outer $x; $x = 0 }
> else { my outer $x; $x = 1 }
>
> $x;
> }
>
> do you? So why make people using closures do it?
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 } }
In the first line, the two $x's both refer to the same thing. In the
second line, they don't. To all intents and puposes the inner $x in the
2nd line is declaring a new lexical which happens to grab the outer $x's
value at the time the anon sub is instantiated.
The reason why removing the 'middle' $x in the following
{ my $x = 'bar'; sub foo { $x; sub {$x} }}
causes the behaviour to change is that the middle $x implicitly gives
foo() a copy of $x at compile time. When the anon sub is cloned,
it picks up the current value of foo()'s $x. Without the middle $x, the
cloned sub picks up the outer $x instead.
Since the use of a bare lexical in a nested sub to all intents and purposes
introduces new variable, I thought it would help *people* for this to
be explicitly shown. It would also resolve some fuzzy scoping issues
by making things explicit. In the following, should the anon sub grab
foo()'s $x or the outer $x ?
{ my $x = 'bar'; sub foo { {$x}; sub {$x} }}
In bleedperl, the outer $x is grabbed, while the following line causes
foo()'s $x to be grabbed:
{ my $x = 'bar'; sub foo { sub {$x}; {$x} }}
Clearly one of them is a bug, but which one? No one on P5Pers seemed to want
to decide.
Use of an 'outer' declaration would make this explicit:
{ my $x = 'bar'; sub foo { outer $x; sub {$x} } # grab foo's $x
{ my $x = 'bar'; sub foo { {outer $x;} sub {$x} } # grab outer $x
Dave "monomania" M.
Re: explicitly declare closures???
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 very nice book
called "Structure and Interpretation of Computer Programs" that can
give you a deep understanding. **
Anyways, it's important to understand that closures do not change the
scoping rules. A closure simply *captures* an existing environment.
If the environment isn't captured properly or changes after capture,
then you have buggy closures.
> causes the behaviour to change is that the middle $x implicitly gives
> foo() a copy of $x at compile time. When the anon sub is cloned,
> it picks up the current value of foo()'s $x. Without the middle $x, the
> cloned sub picks up the outer $x instead.
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 page 260 in "Programming Perl" (3rd ed), Larry/Tom/Jon talk about
how Perl's closures (should) behave:
In other words, you are guaranteed to get the same copy of
a lexical variable each time ...
IMHO bugs in Perl 5 shouldn't carry over to Perl 6. (Unless, of course,
we *like* the bugs... ;)
- Ken
** Unfortunately the term closure has two important meanings that
are not really related. We're talking about closing a subroutine's
environment, which is not how SICP uses the word. If you want a
"Closures For 21 Dummies" sort of book, this is not it.
Re: Expunge implicit @_ passing
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 method. If my redirector eliminated itself, none of this would be possible. 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? - Ken
Re: explicitly declare closures???
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(); $F->();
> >
> > { my $y = 'Y'; sub g { pr $y; $G = sub {pr $y} }}
> > g(); $G->();
>
> X
> Y
> Y
Yes, exactly. It would be a violation of the lexical scoping
rules for $x and $y to print anything differently.
> 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->();
Then I agree.
- Ken
RE: explicitly declare closures???
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->();
>
> Then I agree.
Yes, my example was one cut and paste too early...
;)
Re: Expunge implicit @_ passing
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's non-refcounting GC doesn't provide the same guarantees on when an object whill be finalized.) (And the problem that all too many JVMs have had buggy implementations of finalizers... that's an implementation issue, not a language one, though.) - Damien
Re: Expunge implicit @_ passing
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 non-Perl people. This is not a bad thing, it just means they have to stop expecting the language designer to dictate their whole universe. They can only see hordes of malicious hackers and irresponsible junior programmers blowing away their classes at run-time. As the pendulum swings in the other direction you get mind-bogglingly silly things like finalize which I just learned of today. I'm going to be giving a talk about just this sort of thing at JAOO to a room full of Java people. Should be interesting. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Your average appeasement engineer is about as clued-up on computers as the average computer "hacker" is about B.O. -- BOFH
Re: explicitly declare closures???
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 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!
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(); $F->();
{ my $y = 'Y'; sub g { pr $y; $G = sub {pr $y} }}
g(); $G->();
Dave.
Re: Expunge implicit @_ passing
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. But it's still a bad proportion. goto &$foo should be *faster*. And I mean this as a -language person, not as an -internals person. Tail recursion elimination -- even if it must be explicit, as in perl5 -- should be faster than a recursive call. -- John Porter A word spoken in the mind will reach its own level in the objective truth.
RE: explicitly declare closures???
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!
>
> 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(); $F->();
>
> { my $y = 'Y'; sub g { pr $y; $G = sub {pr $y} }}
> g(); $G->();
X
Y
Y
I'm hardly an authority, but a closure should reflect the environment at
runtime... not compile
You forgot the other example that someone raised:
{ my $x = 'X'; *h = sub { $H = sub {pr $h} }}
h(); $H->();
Which prints:
Z
Re: Something to hash out
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: > > .par for Parrot source, and .pao for Parrot Objects would be cool. I like it. It's a race between those and Randal's .par and .rot (for the bytecode) extensions. > Actually, are these the only two types of file we're going to > generate? Won't there be unoptimized bytecode, parse trees, etc? Do > we want an integrated set of extensions (.pa?)? All that goes into the bytecode files. There probably won't be separate files for 'em. Dan
RE: Expunge implicit @_ passing
> 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 class is > "perfect" or that, > conceptually, your class should have no subclasses. > > The idea that a class is either 'perfect' or 'complete' has to be the > silliest, most arrogant thing I've ever heard! 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 java code can load in extra classes later. However, there are probably some advanced techniques that allow optimization even when there is no "final". Remembering where optimizations were done, and undoing them if necessary, is one possibility. Perl would find this more difficult (there are many more ways to mess with the type system), so a "final" property may actually be useful. > Anyhow, just don't anyone suggest putting this in Perl 6. I know > where you live. Uh Oh :) Dave -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.
Re: Expunge implicit @_ passing
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 that violently blocks reuse! > > On the other hand, it could stop some of the really stupid uses for > inheritance I've seen. Problem is, it stops the smart ones, too. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One I have no choice but be brave and face the danger and laughter! So please don't email me insults. If I don't deserve your belief, at least I deserve your respect. --Alex Chiu, Immortality Guy
Re: finalization
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 finalization to > cleanup resource when an unexpected exception happens. It is more like > a safe-net or parachute. It is most likely to help you in emergency, but > there is no guarantee it will work. > There's a really interesting paper by one of the .NET development team explaining why finalization and GC just don't go together: http://www.mvps.org/vbnet/dev/vb7/vbdotnet_ms_resmanagement.htm 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 options.
Re: finalization
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 options. 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 it's halfway under water and out of file descriptors. -sam
Re: Expunge implicit @_ passing
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 not final, then the compiler can make no such > assumption because java code can load in extra classes later. And a very good reason it is, too. While an optimizing JIT can play tricks to achieve similar results, this won't work for something like gcj which compiles directly to native code. The fact that C++ is usually compiled to native code, while Java is not, may explain why C++ methods are (in Java parlance) final unless explicitly declared "virtual". - Damien
finalization
> 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's non-refcounting GC doesn't provide the > same guarantees on when an object whill be finalized.) (And > the problem > that all too many JVMs have had buggy implementations of finalizers... > that's an implementation issue, not a language one, though.) The finalization is significantly different from DESTROY and destructor. The problem is there is no guarantee the finalization method will be ever called, or when it is called. For example, shall we let exit() to call all finalization methods. It is very likely to cause deadlock. I don't think C++ will unwind all thread stacks and call destructors in this case. 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 finalization to cleanup resource when an unexpected exception happens. It is more like a safe-net or parachute. It is most likely to help you in emergency, but there is no guarantee it will work. Hong
Re: finalization
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 resources. It's not an ideal solution but there doesn't seem to >> be many other practical options. > >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 it's halfway under water and out of >file descriptors. With GC, it is of course again the duty of the programmer to make sure the resources are freed on time: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpapndx/html/_cor_finalize_and_dispose.asp http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguidnf/html/cpconcleaningupunmanagedresources.asp C# has some syntactic sugar to make this a little more convenient to use: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csspec/html/vclrfcsharpspec_8_13.asp Having to do explicit resource management is a real pain when you are used to Perl 5's reference counting. :) BTW, the lure of GC over refcounting is *not* the speed (it is only slightly faster). The advantage is that it takes care of circular references. And it can remove sandbars in your heap for long running processes. It is also supposed to make your programs more robust because you don't have to bother with keeping your reference counts rights. But it has a ton of its own problems with resource management, so I'm not convinced there. -Jan
Re: finalization
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 how fast it is when it's halfway under water and out of > file descriptors. Speaking purely for myself, I'd rather have a non-refcounting GC because I'm rather tired of going through elaborate tricks to avoid ever creating circular data structures. - Damien
Re: finalization
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 > > be many other practical options. > > 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 it's halfway under water and out of > file descriptors. > 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.
RE: finalization
> 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't have to pay malloc overhead. On MP machine, ref count is really slow, because of the atomic instructions, which are very slow. I measured the atomic x86 instruction such as "LOCK INC DWORD PTR [ECX];" long time ago. I believe each instruction takes about 10 to 30 clock cycles. The main issue with GC is the pause. The advanced gc can reduce typical pause to < 10ms most of time. The full gc Hong
Re: finalization
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 the leaky GC boat with Java and C# because we've heard it's >> faster. I wonder how fast it is when it's halfway under water and out of >> file descriptors. > >Speaking purely for myself, I'd rather have a non-refcounting GC >because I'm rather tired of going through elaborate tricks to avoid >ever creating circular data structures. Have you actually tried working in a purely mark-and-sweep style GC environment (Java/.NET)? You don't have deterministic destruction order, which means that effectively you don't have DESTROY *at all*. Don't even think about using finalizers; they are almost completely useless. Everything that needs any kind of cleanup must be managed manually. I find that extremely painful and prefer refcounting any day. Maybe I'm just lazy. Avoiding circular references is not that hard if you never store references into package variables. Just remember to break the circle manually before you loose the last reference to it. :) -Jan
Re: finalization
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 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. The big gain only comes in when your program is small/quick enough to actually finish before the GC kicks in the first time (think CGI). In that case you just discard the whole heap instead of doing a proper garbage collection (unless of course someone thought they could still do something inside a finalizer during global destruction and you still need to finalize every other object on your heap :). >On MP machine, ref count is really slow, because of the atomic instructions, >which are very slow. I measured the atomic x86 instruction such as >"LOCK INC DWORD PTR [ECX];" long time ago. I believe each instruction takes >about 10 to 30 clock cycles. Don't even dream of accessing Perl scalars simultaneously from multiple threads without some kind of locking. To keep their internal caching behavior consistent, you'll need to lock them for even the most simple operations (see the failure of the Perl 5.005 thread model). But even if you give up the caching behavior, what about strings? Atomic updates, eh? Welcome to the world of immutable strings. Just allocate a new string every time you need to modify it and update the string reference atomically. You want a modifiable buffer? Get a StringBuilder object and lock it on every access. :) We could just as well switch to Java or C#. -Jan
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 -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? 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! Wow. I'm reading the Sun tutorial on the subject. Interesting reading. http://java.sun.com/docs/books/tutorial/java/javaOO/final.html 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 class is "perfect" or that, conceptually, your class should have no subclasses. The idea that a class is either 'perfect' or 'complete' has to be the silliest, most arrogant thing I've ever heard! Anyhow, just don't anyone suggest putting this in Perl 6. I know where you live. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Good tidings, my native American Indian friend! America will soon again be yours! Please accept 5th Avenue as an initial return!
RE: Expunge implicit @_ passing
> 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-variable-typed language, such as Java. If the variable is not strongly-typed, people can always use delegation or has-a scheme to subvert the class, even the class itself is declared as final. For a truly well designed class, which has no public/protected fields, nor protected methods, it really does not matter whether it is final or not, since the subclass can not do anything beyond the class' public interface. Unless we want Perl to be strongly typed everywhere, I doubt the usefulness of final except documentation purpose. Hong
RE: Expunge implicit @_ passing
# -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 -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? # # 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! 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! (It was private inheritance, so you couldn't tell this from the outside.) This was one of the biggest kludges I've ever seen, and a good example of a bad use of is-a. It also meant that the class was nearly impossible to modify for different storage--it was far easier to just write a new class with the same interface. Stupid, stupid, stupid. --Brent Dax [EMAIL PROTECTED]
