Re: Apocalypse 4 : The Strange Case of the STRANGE CASE
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 the 'big picture'. (Plus you'd get into problems with NEXT vs next etc.) Tim. [*] Historical note: This actually came about partly because the DBI ties a hash ref into the same class that the hash is blessed into. Perl's tie FETCH method used to be called fetch, but that clashed with the DBI's own fetch method. On Tue, Jan 22, 2002 at 05:40:47PM +, Andy Wardley wrote: I was reading Apocalypse 4 and was perturbed by the strange and inconsistent looking use of UPPER and lower case in various keywords. Now before anyone rushes to assist me in understanding the logic, I should say that we've already thrashed this out on the London.pm mailing list and several people (Hi Piers :-) have re-iterated the reasoning being the use of upper vs lower case. In a nutshell, UPPER CASE is reserved for special Perl blocks that should stand out to the user due to the fact that they represent exception flow control. It's a good, logical and consistent argument for sure, but sorry, I don't buy it. We end up with peculiarities like 'try/CATCH'. Even if 'try' is a keyword and 'CATCH' is a special block, I can't see any valid reason for having them different case. Same with 'last/NEXT' - they're so similar in concept that the implementation details should not matter. By this argument, I could claim that the correct capitalisation of knife and FORK is based on the rule cutting things are in lower case, spiking things are in UPPER CASE. It's consistent and logical, but common sense should tell you that it's plain wrong. INIT, DESTROY, AUTOLOAD, etc., all make sense to me. They really are special blocks that normally only occur once in a file. But CATCH and NEXT are part of normal syntax. I don't think they're any more unusual in their flow control than try, while, loop or foreach. I think this needs a rethink. What do other people think? A
Re: Some Apocalypse 4 exception handling questions.
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. NEXT, LAST, KEEP, UNDOin reverse order
3. POST in reverse order, inherited, no side effects
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?
class A;
sub foo($bar,$baz){
PRE{ $bar10 }
my $qux=$baz;
POST{ $qux==$baz }
}
class B is base(A); # I forget the syntax for inheritance
sub foo($x,$y){
# Insert any old random code here
}
Presumably, PRE/POST blocks will only be able to access their sub's
arguments, since the derived class' sub may not declare the same variables
as the base class (see $qux above). Or, maybe you just can't inherit from
methods with such conditions, but I think that's putting the restriction in
the wrong place. Or, you only inherit conditions which are inheritable, but
that defeats the whole scheme.
Also, these references have to be compiled into accesses to the argument
list, rather than to the lexicals, otherwise they won't be any use at all to
the derived class. Of course, this might be how references to sub arguments
are compiled anyway, in which case there's no problem.
--
Peter Haworth [EMAIL PROTECTED]
Master, does Emacs have the Buddha nature? the novice asked.
The Chief Priest had been in the temple for many years and could be
relied upon to know these things. He thought for several minutes before
replying, I don't see why not. It's got bloody well everything else.
RE: Some Apocalypse 4 exception handling questions.
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 want to inherit PRE conditions. DBC allows a derived method to strengthen (add) post-conditions; but to weaken (remove) preconditions. I haven't (yet) seen how this weakening would be accomplished. Perhaps the mechanism that controls inheritance of preconditions may have a more general applicability? Dave.
Re: Apocalypse 4 : The Strange Case of the STRANGE CASE
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 various definitions of fix ;-) I'm not uncomfortable with the apparent try/CATCH inconsistency. Same here. People are just used to try/catch from other languages that are philisophically bent different. That just makes try/CATCH inconsistent with those languages, not with Perl. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Apocalypse 4 : The Strange Case of the STRANGE CASE
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 enough to catch import() though. Oh well ... Perl 6 will :fix that. (For various definitions of fix ;-) import() is not called automatically by Perl. It's called automatically by the module Exporter.pm. Subtle but important difference there. Casey West -- Shooting yourself in the foot with Mach The bullets work pretty well, but they don't make guns for it any more.
Re: Apocalypse 4 : The Strange Case of the STRANGE CASE
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 automatically for you should have :: all-caps names[*]. :: ::Not early enough to catch import() though. Oh well ... Perl 6 will ::fix that. (For various definitions of fix ;-) : :import() is not called automatically by Perl. It's called :automatically by the module Exporter.pm. Subtle but important :difference there. My bad, that's wrong. I think what my brain wanted to say is that it is lowercase because Exporter.pm came before use() or something like that. Where was my morning coffee hiding today? Casey West -- Shooting yourself in the foot with Cray You shoot yourself in the foot with an Uzi.
Re: Some Apocalypse 4 exception handling questions.
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 clean up code that frees some resources. If you inherit from that method, and do not inherit the LAST block, then you've got a leak. This is obviously a mild example. --me
RE: Some Apocalypse 4 exception handling questions.
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 to a method. In the LAST block you write clean up code that frees some resources. If you inherit from that method, and do not inherit the LAST block, then you've got a leak. This is obviously a mild example. Methods can be inherited. Their implementations may include LAST blocks, which will be invoked along with the inherited method if the method is not redefined in a subclass. However, if the method is redefined in a subclass, neither the superclass' method's implementation or its associated LAST block would be invoked. In contrast, pre- and post-conditions _are_ inherited and separate from the method implementation itself. If an inherited method is redefined in a subclass, it must still satisfy pre- and post-conditions.
RE: Some Apocalypse 4 exception handling questions.
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 methods? There's another issue: sometimes we don't want to inherit PRE conditions. DBC allows a derived method to strengthen (add) post-conditions; but to weaken (remove) preconditions. I haven't (yet) seen how this weakening would be accomplished. In regard to Design-by-Contract, Larry did say more on that later. -Didn't he? In Class::Contract, pre-conditions are allowed to weaken by allowing either the satisfaction of the subclassed method's pre-conditions or by satisfying the pre-conditions of all classes from which it is derived.
need help making auction
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;
#-###
#
# In accordance with the GPL, this copyright notice MUST remain intact:
#
# EveryAuction Release Version 1.51 (5/13/00)
# Copyright (C) 2000 EverySoft
# Registered with the United States Copyright Office, TX5-186-526
# http://www.everysoft.com/
#
#-###
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
#
#-###
#
# Modification Log (please add new entries to bottom):
#
# * 02/2000
# Matt Hahnfeld ([EMAIL PROTECTED]) - Original Concept and Design
# Version available from http://www.everysoft.com/
#
# * MM/
# Name (email) - Modification
# Availability
#
#-###
#-#
# Configuration Section
# Edit these variables!
local %config;
# The Base Directory. We need an
# absolute path for the base directory.
# Include the trailing slash. THIS SHOULD
# NOT BE WEB-ACCESSIBLE!
$config{'basepath'} = '/home/hahnfld/auctiondata/';
# Closed Auction Directory
# This is where closed auction items are stored.
# Leave this blank if you don't want to store
# closed auctions. It can potentially take
# up quite a bit of disk space.
$config{'closedir'} = 'closed';
# User Registration Directory
# This is where user registrations are stored.
# Leave this blank if you don't want to
# require registration. It can potentially
# take up quite a bit of disk space.
$config{'regdir'} = 'reg';
# List each directory and its associated
# category name. These directories should
# be subdirectories of the base directory.
%category = (
computer = 'Computer Hardware and Software',
elec = 'Consumer Electronics',
other = 'Other Junk',
);
# This is the password for deleting auction
# items.
$config{'adminpass'} = 'auction';
# You need to assign either a mail program or
# a mail host so confirmation e-mails can
# be sent out.
# Leave one commented and one uncommented.
#
# YOU NEED EITHER A MAIL PROGRAM
# $config{'mailprog'} = '/usr/lib/sendmail -t';
#
# OR YOU NEED A MAIL HOST (SMTP)
$config{'mailhost'} = 'localhost';
# This line should be your e-mail address
$config{'admin_address'} = '[EMAIL PROTECTED]';
# This line should point to the URL of
# your server. It will be used for sending
# you have been outbid e-mail. The script
# name and auction will be appended to the
# end automatically, so DO NOT use a trailing
# slash. If you do not want to send outbid
# e-mail, leave this blank.
$config{'scripturl'} = 'www.your.host.com';
# This will let you define colors for the
# tables that are generated and the
# other page colors. The default colors
# create a nice professional look. Must
# be in hex format.
$config{'colortablehead'} = '#BB';
$config{'colortablebody'} = '#EE';
# Site Name (will appear at the top of each page)
$config{'sitename'} = 'Your Site Name Here';
# You can configure your own header which will
# be appended to the top of each page.
$config{'header'} =EOF;
HTML
HEAD
TITLE$config{'sitename'} - Powered By EveryAuction/TITLE
/HEAD
BODY TEXT=#00 BGCOLOR=#FF LINK=#88 VLINK=#88 ALINK=#88
TABLE WIDTH=100\% BORDER=0TRTD VALIGN=TOP WIDTH=100\%
FONT SIZE=+2$config{'sitename'}/FONT
BR
FONT SIZE=+1Online Auction/FONT
/TDTD VALIGN=TOP ALIGN=LEFT
FORM ACTION=$ENV{'SCRIPT_NAME'} METHOD=POST
INPUT TYPE=TEXT NAME=searchstring
INPUT TYPE=SUBMIT VALUE=Search
INPUT TYPE=HIDDEN NAME=action VALUE=search
FONT SIZE=-2INPUT TYPE=RADIO NAME=searchtype VALUE=keyword
CHECKEDkeyword INPUT TYPE=RADIO NAME=searchtype VALUE=usernameusername /FONT
/FORM
/TD/TR/TABLE
P
EOF
# You can configure your own footer which will
# be appended to the bottom of each page.
# Although
Re: Some Apocalypse 4 exception handling questions.
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 the : LAST block you write clean up code that frees some : resources. If you inherit from that method, and do not : inherit the LAST block, then you've got a leak. This is : obviously a mild example. I think our terminology is getting sloppy here. What do you mean by inherit from that method? If the derived method overrides the base method, it will manage its own resources, and doesn't need the base method's LAST. If the derived method calls the base method, the LAST of the base method will naturally come along for the ride. If there is no derived method, the base method also calls its own LAST as a matter of course. I don't see any problem here. Larry
Re: need help making auction
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
Re: need help making auction
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:http://www.everysoft.com/frames.html Online Forum: http://209.15.166.219/cgi-bin/forum.pl Please go to their forum and ask them to help you, I'm sure they would be more than happy to. No further response is necessary. Casey West -- Technology makes it possible for people to gain control over everything, except over technology. -- John Tudor
Re: Some Apocalypse 4 exception handling questions.
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 block you write clean up code that frees some resources. If you inherit from that method, and do not inherit the LAST block, then you've got a leak. This is obviously a mild example. 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) work. In my mind, the idea of inheriting a method is that the subclass and the superclass have a common subroutine that is invoked whether the message is sent to the subclass or to the superclass. In Perl6 terms, that subroutine may include PRE/POST blocks, FIRST/LAST/NEXT/CATCH/UNDO/KEEP blocks, embedded closures and other statements, whatever the implementation needs to be to get the job done correctly. The whole she-bang subroutine implementation comes along for the inheritance ride. The idea that has been mentioned of having PRE and POST blocks be inherited is a slightly different concept... in that case, the method itself is NOT being inherited, and NONE of the code of the method in the superclass is used by the subclass... Except the PRE and POST conditions, as implemented by the PRE and POST blocks. They would get inherited to allow the design by contract invariants required by the superclass to be enforced in spite of subclassing. This separate type of inheritance is another reason that perhaps the PRE and POST blocks should not be included within the block of the subroutine that implements a method, but perchance should be defined outside of them... perhaps as properties of the method definition? I would be extremely doubtful of Larry's lucidity if I thought that he was suggesting that none of the FIRST/LAST/NEXT/CATCH/UNDO/KEEP blocks were included with an inherited method, but I don't think that. Such blocks are an inherent part of the implementation of the method, not an inherit part of subclassing. What do you think, me? --me -- Glenn = Due to the current economic situation, the light at the end of the tunnel will be turned off until further notice.
Re: need help making auction
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, -Melvin
Re: Some Apocalypse 4 exception handling questions.
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 another issue: sometimes we don't want to inherit PRE : conditions. DBC allows a derived method to strengthen (add) : post-conditions; but to weaken (remove) preconditions. I : haven't (yet) seen how this weakening would be accomplished. Damian told me you just handle that by ORing together the preconditions, but ANDing the postconditions. : Perhaps the mechanism that controls inheritance of : preconditions may have a more general applicability? Underneath it's all just block properties that happen to be closures. We can do whatever we want with them--as long as we agree on the definitions of we and want. Or at least agree to disagree such that we keep out of each other's way. Larry
Re: Some Apocalypse 4 exception handling questions.
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 of methods
(should) work.
Eek.
In my mind, the idea of inheriting a method is that the subclass and the
superclass have a common subroutine that is invoked whether the message
is sent to the subclass or to the superclass. In Perl6 terms, that
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 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 words, when you inherit a method, you are taking the
base implementation for that method. But if you replace a method, you
are not inheriting that method, but rather replacing it; yes, the
replacement method may choose to call the base implementation's method
as part of the replacement implementation. When you replace a method,
you have 2 subroutines, the base implementation, and the replacement
implementation, but when you inherit a method, you have only 1
subroutine, which may be called 2 different ways.
If you have hidden side effects that makes things scary, (and potentially
costly in the long run) I think.
I wasn't positing hidden side effects. I was trying to not inherit
fragments of the base implementation, as me seemed to be trying to do.
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 rephrase it, so we can talk more
about it.
-Melvin
--
Glenn
=
Due to the current economic situation, the light at the
end of the tunnel will be turned off until further notice.
Re: Some Apocalypse 4 exception handling questions.
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 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 words, when you inherit a method, you are taking the
base implementation for that method. But if you replace a method, you
are not inheriting that method, but rather replacing it; yes, the
replacement method may choose to call the base implementation's method
as part of the replacement implementation. When you replace a method,
you have 2 subroutines, the base implementation, and the replacement
implementation, but when you inherit a method, you have only 1
subroutine, which may be called 2 different ways.
After re-reading your piece by itself I see we did say the same thing.
The confusion set in when I read 'Me's' post inline with yours.
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 rephrase it, so we can talk more
about it.
Referring to final, private, etc. modifiers that you can use in C++/Java
whenever you don't want someone reimplementing or overriding something.
Will there be such a thing in Perl6?
I think this is meant more for Me (not me) than you.
-Melvin
Re: Some Apocalypse 4 exception handling questions.
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 rephrase it, so we can talk more about it. Referring to final, private, etc. modifiers that you can use in C++/Java whenever you don't want someone reimplementing or overriding something. Will there be such a thing in Perl6? I think this is meant more for Me (not me) than you. final and private are completely different concepts as I understand them. At least, I think I understand private to be stuff used by the implementation of methods, that is not available for the general public to see. This is considered a good thing in compiled code where users code to the interface, and cannot see the implementation. In Perl, the implementation is generally visible, and privacy would be somewhat fictitious, albeit perhaps a useful one at times. 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 idea for a useful subclass for the class or method, but run into the problem of not being able to extend it because of the superclass implementor's choice to make it final. Hence, final seems to be a concept that is rather un-Perl-ish. -- Glenn = Due to the current economic situation, the light at the end of the tunnel will be turned off until further notice.
Re: Some Apocalypse 4 exception handling questions.
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 words, when you inherit a method, you are taking the base implementation for that method. But if you replace a method, you are not inheriting that method, but rather replacing it; yes, the replacement method may choose to call the base implementation's method as part of the replacement implementation. When you replace a method, you have 2 subroutines, the base implementation, and the replacement implementation, but when you inherit a method, you have only 1 subroutine, which may be called 2 different ways. But the base class may be just an interface class. And thus by inheriting the pre conditions you are enforcing the API. So I can see a use for it, but I can also see where you don't want it too. Graham.
Re: Some Apocalypse 4 exception handling questions.
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 the code is not. One can optionally not inherit the conditions (at least preconditions, from another post I just read). And one can optionally inherit the code (by calling it). Right? Btw, are you going to have an equivalent of super? --me
Re: Some Apocalypse 4 exception handling questions.
[final, private] I detest what these modifiers have done to me in the past. They seem very unperlish to me.
Re: Some Apocalypse 4 exception handling questions.
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 idea for a useful subclass for the class or method, but run into the problem of not being able to extend it because of the superclass implementor's choice to make it final. Hence, final seems to be a concept that is rather un-Perl-ish. Hmm. It would be un-Perl-ish to not provide a mechanism for the fascist to implement final if they wanted it. Which leads me to wonder if a way unfolds from the syntax already revealed or if we have to wait for the OOP-Apocalypse to see how to put our PRE conditions on the isa mechanism. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Some Apocalypse 4 exception handling questions.
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 omniscient the original designer is, someone will get an idea for a useful subclass for the class or method, but run into the problem of not being able to extend it because of the superclass implementor's choice to make it final. Hence, final seems to be a concept that is rather un-Perl-ish. Hmm. It would be un-Perl-ish to not provide a mechanism for the fascist to implement final if they wanted it. Which leads me to wonder if a way unfolds from the syntax already revealed or if we have to wait for the OOP-Apocalypse to see how to put our PRE conditions on the isa mechanism. I agree totally. Ive never bought into arguments about why available, non-default behavior is so oppressive. Else use strict would have to go. :) Glenn's point is correct about these mechanisms - when you don't have access to source code, it can be frustrating, but I think its the availability of source + the design decision of the author, not the keyword that is the problem. -Melvin
Re: Some Apocalypse 4 exception handling questions.
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 _replacement_ method. In other words, when you inherit a method, you are taking the base implementation for that method. But if you replace a method, you are not inheriting that method, but rather replacing it; yes, the replacement method may choose to call the base implementation's method as part of the replacement implementation. When you replace a method, you have 2 subroutines, the base implementation, and the replacement implementation, but when you inherit a method, you have only 1 subroutine, which may be called 2 different ways. But the base class may be just an interface class. And thus by inheriting the pre conditions you are enforcing the API. So I can see a use for it, but I can also see where you don't want it too. So if the base class is just an interface class, then you cannot usefully inherit the methods, without winding up with just another interface class. Of course, that sometimes is useful too. So maybe your point was that when you replace a method from a base class that you only have 1 subroutine for that method, the replacement one, because there wasn't really one there in the interface class to inherit? It was not my intention in the paragraph I quoted to say anything about pre and post conditions, but neither was it my intention to imply that they shouldn't be inherited, if they exist. I'd still like to hear Larry comment on the benefits vs dangers of having the PRE and POST conditions defined within the implementation block of a method, as opposed to defined outside. The more I think about it, the more convinced I am that the natural place to define the pre and post conditions is outside the implementation block, to prevent them from referencing lexically scoped variables of the implementation... or have a compiler rule preventing it. Otherwise they could be impossible to evaluate in the context of an inherited (replacement) method. -- Glenn = Due to the current economic situation, the light at the end of the tunnel will be turned off until further notice.
Apoc4: Block scoping
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, grep, loop, and given.
Thanks,
cd
RE: [dha@panix.com: Re: ^=~]
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 = reduce @data { combinator() };
I would love this. From an OO point of view, it looks much more natural imho
to think on map and friends as list methods that take block arguments than
as block methods that take arrays as arguments.
In other words:
@result = @data.map(mapping)
looks better than:
@result = mapping.map(@data)
Then you would have the possibility of:
@result = map @data - $x { mapping($_, $x) }
...
I am afraid I don't understand this one. ¿Which value is $_ suposed to get?
The Perl5-ish:
@sorted_by_size =
map { $_-[0] }
sort { $a-[1] = $b-[1] }
map { [$_, -s] }
@files;
would become:
@sorted_by_size =
map sort map @files
{ [$_, -s] }
{ $^a[1] = $^b[1] }
{ $_[0] };
Though I suppose the method call approach solves that nicely too:
@sorted_by_size =
@files.map( { $_[0] })
.sort({ $^a[1] = $^b[1] })
.map( { [$_, -s] });
with the operations reading left-to-right, down the page.
Mmm.. If we did reverse the order of the arguments I was expecting it to
become:
@sorted_by_size =
@files.map({ [$_, -s] })
.sort({ $^a[1] = $^b[1] })
.map({ $_[0] })
Or if that was not decided, then I would expect:
@sorted_by_size = { $_[0] }.map (
{ $^a[1] = $^b[1] }.order (
{ $^a[1] = $^b[1] }.map (@files)
)
);
By the way, assuming the order of list manipulation operators was actually
reversed, ¿would the following be correct perl6?
@sorted_by_size =
@files.map - $file { [$file, -s $file] }
.sort - @a, @b { @a[1] = @b[1] }
.map - @pair { @pair[0] }
--
Angel Faus
[EMAIL PROTECTED]
Re: Apoc4: Block scoping
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 demonstrates it with for, grep, loop, and given.
I haven't decided whether it makes sense for Cif or Cwhile to try
to pass anything to their blocks. We'd either have to hardwire it
syntactically to look for - and do something different, which is icky,
or we'd have to make it assume - $_ when there wasn't an arrow, which
is ickier. People aren't going to expect $_ to get overridden like
that.
Larry
Re: Some Apocalypse 4 exception handling questions.
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 the derived method calls the base method, the LAST Larry of the base method will naturally come along for the ride. If there is Larry no derived method, the base method also calls its own LAST as a matter Larry of course. I don't see any problem here. That's why I'm still puzzled about what it means to inherit PRE/POST as well. A block of code doesn't have a superclass. What exactly are you inheriting from? If you call super from a method, surely the super will have its own PRE/POST, and then there's no need to inherit it. If you don't call super, how do you know the PRE/POST of a similar subroutine in a superclass that you're completely overriding should even apply? So, does it make any sense at all to talk about inheriting PRE/POST as a separate act, other than the natural block start/end from calling super at the right time? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
