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
>
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 va
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 a
Casey West:
# 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-cap
> 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 cl
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
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 inherite
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 Page:
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. I
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,
>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 of methods
>(should) wo
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'
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 inher
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 metho
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 matt
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 ot
> 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 th
> [final, private]
I detest what these modifiers have done to me
in the past. They seem very unperlish to me.
At 02:45 PM 1/23/2002 -0800, Glenn Linderman wrote:
>Melvin Smith wrote:
> > Referring to final, private, etc. modifiers that you can use in C++/Java
> > whenever you don't want someone reimplementing or overriding something.
>
>final and private are completely different concepts as I understand
>
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 a
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 o
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 C 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, g
>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 C 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
32 matches
Mail list logo
