Early on in the life of Perl 5 Larry adopted the convention that
subroutines that Perl calls automatically for you should have
all-caps names[*].
I'm not uncomfortable with the apparent try/CATCH inconsistency.
I suspect that having CATCH etc. be lowercase would create a greater
inconsistency in
On Tue, 22 Jan 2002 10:03:08 -0800 (PST), Larry Wall wrote:
At the moment, I see this:
-2. PRE in order, inherited, no side effects
-1. FIRST in order
0. inline code normal flow
1. CATCH, CONTROLsingular
2.
Peter Haworth [mailto:[EMAIL PROTECTED]] wrote:
This is all very sensible, and I completely agree with it.
However, don't we
need some restrictions on what can go in PRE and POST blocks
to ensure that they are still valid in inherited methods?
There's another issue: sometimes we don't
On Wed, Jan 23, 2002 at 11:50:54AM +, Tim Bunce wrote:
Early on in the life of Perl 5 Larry adopted the convention that
subroutines that Perl calls automatically for you should have
all-caps names[*].
Not early enough to catch import() though. Oh well ... Perl 6 will
fix that. (For
On Wed, Jan 23, 2002 at 01:45:44PM -0600, Jonathan Scott Duff wrote:
:
:On Wed, Jan 23, 2002 at 11:50:54AM +, Tim Bunce wrote:
: Early on in the life of Perl 5 Larry adopted the convention that
: subroutines that Perl calls automatically for you should have
: all-caps names[*].
:
:Not early
On Wed, Jan 23, 2002 at 03:21:37PM -0500, Casey West wrote:
:
:On Wed, Jan 23, 2002 at 01:45:44PM -0600, Jonathan Scott Duff wrote:
::
::On Wed, Jan 23, 2002 at 11:50:54AM +, Tim Bunce wrote:
:: Early on in the life of Perl 5 Larry adopted the convention that
:: subroutines that Perl calls
The problem I see with inheriting subblocks such as
FIRST/LAST/etc, is that they are tied in with the logic
... of their enclosing block...
Surely this is an argument *for* it being pretty odd
*not* to inherit them.
Let's say you add a LAST block to a method. In the
LAST block you write
From: Me [mailto:[EMAIL PROTECTED]]
The problem I see with inheriting subblocks such as
FIRST/LAST/etc, is that they are tied in with the logic
... of their enclosing block...
Surely this is an argument *for* it being pretty odd
*not* to inherit them.
Let's say you add a LAST block
From: David Whipp [mailto:[EMAIL PROTECTED]]
Peter Haworth [mailto:[EMAIL PROTECTED]] wrote:
This is all very sensible, and I completely agree with it.
However, don't we
need some restrictions on what can go in PRE and POST blocks
to ensure that they are still valid in inherited
see attached file.
=
frank crowley
__
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/
#!/usr/bin/perl
use vars qw(%config %category %form);
use strict;
Me writes:
: The problem I see with inheriting subblocks such as
: FIRST/LAST/etc, is that they are tied in with the logic
: ... of their enclosing block...
:
: Surely this is an argument *for* it being pretty odd
: *not* to inherit them.
:
: Let's say you add a LAST block to a method. In
At 01:39 PM 1/23/2002 -0800, frank crowley wrote:
see attached file.
=
frank crowley
What is it that you wanted us to see?
-Melvin
On Wed, Jan 23, 2002 at 01:39:09PM -0800, frank crowley wrote:
:
:see attached file.
Hi frank,
This mailing list is not designed to help folks get their Perl 5
programs working. EverySoft, the company that built the program you
attatched has their own online forum for helping you.
Home
Me wrote:
The problem I see with inheriting subblocks such as
FIRST/LAST/etc, is that they are tied in with the logic
... of their enclosing block...
Surely this is an argument *for* it being pretty odd
*not* to inherit them.
Let's say you add a LAST block to a method. In the
LAST
At 01:43 PM 1/23/2002 -0800, you wrote:
i need help on making it into an auction that will
work.
Ok I thought so.
You might try [EMAIL PROTECTED] for some beginner
tips but I doubt you want to submit a whole script, maybe
rephrase your stuff into specific problems you are having.
Good luck,
David Whipp writes:
: Peter Haworth [mailto:[EMAIL PROTECTED]] wrote:
: This is all very sensible, and I completely agree with it.
: However, don't we
: need some restrictions on what can go in PRE and POST blocks
: to ensure that they are still valid in inherited methods?
:
:
: There's
Melvin Smith wrote:
Methinks (that's me, not you) that if me thinks (that's you, not me)
that my argument is an argument *for* it being pretty odd *not* to
inherit them, that there is an assumption by me or me (that's one or the
other of us) that is clearly wrong about the way inheritance
At 02:25 PM 1/23/2002 -0800, Glenn Linderman wrote:
Melvin Smith wrote:
I'm not comfortable with this sort of concept. Typically inheritance is
going to either take the base implementation or _replace_ the
implementation.
The replacement can decide to {call|ignore} the base method.
I
Melvin Smith wrote:
If you wouldn't want the base implementation to be ignore there is usually
some mechanism in C++ and Java for this, how it applies to Perl6 I'm not
sure.
I'm not sure either. In fact, I'm not sure what you mean by this
sentence at all. If it matters, please
On Wed, Jan 23, 2002 at 02:25:35PM -0800, Glenn Linderman wrote:
I think you just said the same thing I did. To be more explicit, using
the terminology you seem to want to use, I'll point out that I was only
talking about the case of an inherited method, not a _replacement_
method. In other
I think our terminology is getting sloppy here.
Ok, I (think I) understand. It's simple:
If you declare a derived method, then preconditions
and postconditions may or may not be inherited, and
independently, the code may or may not be inherited.
By default, the conditions are inherited and
[final, private]
I detest what these modifiers have done to me
in the past. They seem very unperlish to me.
On Wed, Jan 23, 2002 at 02:45:21PM -0800, Glenn Linderman wrote:
Final seems to be a way of sealing off a class or method from future
inheritance. Generally, the arguments I've seen on OO lists seem to
indicate that regardless of how omniscient the original designer is,
someone will get an
At 05:01 PM 1/23/2002 -0600, Jonathan Scott Duff wrote:
On Wed, Jan 23, 2002 at 02:45:21PM -0800, Glenn Linderman wrote:
Final seems to be a way of sealing off a class or method from future
inheritance. Generally, the arguments I've seen on OO lists seem to
indicate that regardless of how
Graham Barr wrote:
On Wed, Jan 23, 2002 at 02:25:35PM -0800, Glenn Linderman wrote:
I think you just said the same thing I did. To be more explicit, using
the terminology you seem to want to use, I'll point out that I was only
talking about the case of an inherited method, not a
Does the alias operator, C - , work for Cif blocks too?
if $a * $b / $c + $d - $abcd { ... }
Where $abcd would be lexically scoped to the if block and else block,
if defined. I expect it could be used with any block statement,
since Apoc 4 demonstrates it with for,
Damian Conway [mailto:[EMAIL PROTECTED]] wrote:
You *could* instead consider reversing the arguments to all the list
manipulation operators:
@result = map @data { mapping() }
@result = grep @data { selector() };
@result = sort @data { comparison() };
@result =
Chris Dale writes:
: Does the alias operator, C - , work for Cif blocks too?
:
: if $a * $b / $c + $d - $abcd { ... }
:
: Where $abcd would be lexically scoped to the if block and else block,
: if defined. I expect it could be used with any block statement,
: since Apoc 4
Larry == Larry Wall [EMAIL PROTECTED] writes:
Larry I think our terminology is getting sloppy here. What do you mean by
Larry inherit from that method? If the derived method overrides the base
Larry method, it will manage its own resources, and doesn't need the base
Larry method's LAST. If
29 matches
Mail list logo
