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
test_main needed an overhaul on options handling, and if/then/else was
breeding like rabbits. This one is 41 lines shorter and easier to read.
Please test before I commit.
-Melvin
Index: test_main.c
===
RCS file: /cvs/public/parro
Eek, don't apply that, I see a bug, I'll post a new one in a sec.
-Melvin
At 02:52 PM 1/23/2002 -0500, Melvin Smith wrote:
>test_main needed an overhaul on options handling, and if/then/else was
>breeding like rabbits. This one is 41 lines shorter and easier to read.
>
>Please test before I commi
Modified version of last patch. Fixed in case -f flag wasn't provided a
file or "-" arg.
-Melvin
Index: test_main.c
===
RCS file: /cvs/public/parrot/test_main.c,v
retrieving revision 1.36
diff -u -r1.36 test_main.c
--- test_main.c
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
Ok, here is the updated schemepair-patch.
The diff is agains a fresh update of anoncvs and should hopefully apply
clean.
A Pair is implemented as an array with exact 2 elements. This elements
may be PMC values, especially other Pairs. The car-element is index 0,
the cdr-element is index 1.
Li
[EMAIL PROTECTED] (Russ Allbery) wrote on 22.01.02 in
<[EMAIL PROTECTED]>:
> Kai Henningsen <[EMAIL PROTECTED]> writes:
>
> > A case that (in a slightly different context) recently came up on
> > alt.usage.german (I don't remember if this particular point was made,
> > but it belongs):
>
> > "b
> 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
On Wed, Jan 23, 2002 at 06:06:00PM +0200, Kai Henningsen wrote:
> People do get confused sometimes.
I'm confused as to why this is still on p6i. Followups to alt.usage.german?
Thanks.
--
DESPAIR:
It's Always Darkest Just Before it Gets Pitch Black
> "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
I just wanted to give everyone a quick summary of the status of tinderbox
and bonsai. Tinderbox is up and running at tinderbox.perl.org. If people
would like, I can configure a little bot for #parrot so that it will let
everyone know if the tinderbox state changes (but won't annoy people in
other
>different colors mean. There are also no clients for windows or other rare
>OS's now. It would be great if we could get one going. I'll do the best that
>I can to help get it setup.
I remember trying a month or so ago and it appeared that the Tinderbox
module used sendmail wrapper for sending t
It is still using sendmail though I am working on a Net::SMTP version for
the next release. If you can give me a few days I'll have it up on CPAN.
Thanks for volunteering to contribute.
Zach
On 1/23/02 7:15 PM, "Melvin Smith" <[EMAIL PROTECTED]> wrote:
>
>> different colors mean. There are als
41 matches
Mail list logo
