Personally, I like to be able to directly access the symbol table. It is
nice when generating classes from a template. I hope typeglobs go in the
washing machine instead of the bathtub. But, I don't mind it they are hard
to recognize when they come back.
Garrett
To me, Perl is like a good book. It's a good quick read that takes you in
quickly and entertains you without wasting your time. But you can also go
back and re-read it again and again, and each time you re-examine it you
find another level of depth and complexity.
As a programming language, it is
http://msdn.microsoft.com/library/default.asp?URL=/library/prelim/csref/vcor
iCReference.htm
From: Larry Wall [mailto:[EMAIL PROTECTED]]
>
> Here's another article that talks about a lot of the things we
> *should* be thinking. In fact, it's possible this article should
> be required reading for anyone who aspires to be a Perl designer.
>
> http://windows.oreilly.com/news/hejlsberg_0800.
$want_deep_copy++;
$want_deep_equal++;
From: Mark-Jason Dominus [mailto:[EMAIL PROTECTED]]
>
> Lisp, which you might expect would have a 'deep copy' operator,
> doesn't have one. The Lisp folks have apparently thought about this
> very carefully, and decided that the semantics are unclear, an
Here's a version of my own kludgey deep copy. -Updated to use our mythical
->CLONE method, and watch for circular references...
our %SEEN = ();
our $DEPTH = 0;
%a = (a => 1, b => 2, c => [{a => 1, b => [1,2,3]}, 1, 2, 3]);
*b = dcopy(\%a);
sub dcopy { # Dereference and return a deep copy of wha
Oops, my circular ref code is/was screwy...
> --$DEPTH
> and $SEEN{$_} = ref($rval)
> or $SEEN = ();
should be
> --$DEPTH
> and $SEEN{$_} = $rval
> or $SEEN = ();
From: Peter Scott [mailto:[EMAIL PROTECTED]]
>
> >I would like deep copying to include copying CODE. It would
> >be useful for implementing object methods...
>
> Why would it be necessary to deep copy a CODE reference?
It might not be necessary. I'm still learning how to write kosher Perl...
el
> From: Damian Conway [mailto:[EMAIL PROTECTED]]
>
> > One could make dump "work" by having it dump out not a core or
> > a.out, but rather the byte codes representing the current state of
> > the perl machine. This seems anywhere from somewhat to seriously
> > useful, and follows in the spirit
From: Jonas Liljegren [mailto:[EMAIL PROTECTED]]
>
> Does any other RFC give the equivalent to an 'in' operator?
>
> I have a couple of times noticed that beginners in programming want to
> write if( $a eq ($b or $c or $d)){...} and expects it to mean
> if( $a eq $b or $a eq $c or $a eq $d ){...
From: Bart Lateur [mailto:[EMAIL PROTECTED]]
>
> On Wed, 06 Sep 2000 13:04:51 -0500, David L. Nicol wrote:
>
> > grep { $a > $_ and last } @b)
>
> So "last" should return true, or what?
The last operator doesn't return anything does it? It immediately exits the
loop/block in question.
@p
From: Damian Conway [mailto:[EMAIL PROTECTED]]
>
> From: Garrett Goebel
> > @passed = grep { 2 > $_ and last } (1, 2, 3, 2, 1);
> >
> > would leave
> > @passed = (1, 2)
>
> I believe the above would leave:
>
> @passed = ();
>
> sin
From: Bart Lateur [mailto:[EMAIL PROTECTED]]
>
> On Wed, 6 Sep 2000 16:24:41 -0500 , Garrett Goebel wrote:
> >> > grep { $a > $_ and last } @b)
> >>
> >> So "last" should return true, or what?
> >
> >The last operator doesn
Would it be possible to expand the function prototypes so that a function
could be defined to take a loop block instead of a code block?
From: Damian Conway [mailto:[EMAIL PROTECTED]]
>> >> my_while { pred() } { # don't gimme no Tcl flac.
>> >> ...
>> >> } # no semicolon needed here!
>>
>> DC> Just added to the RFC :-)
>>
>> How would the parser handle this? Some '}' would need
> ';' some don't.
>
> Th
From: John Porter [mailto:[EMAIL PROTECTED]]
>
> Garrett Goebel wrote:
> > Would it be possible to expand the function prototypes so
> > that a function could be defined to take a loop block
> > instead of a code block?
>
> Might be easier to do what I suggested,
From: 'John Porter' [mailto:[EMAIL PROTECTED]]
>
> Garrett Goebel wrote:
> > However it still doesn't answer how you are able to:
> >
> > return $true and next;
> > return $false and next;
> > return $true and last;
> > return $false a
From: Peter Scott [mailto:[EMAIL PROTECTED]]
>
> I don't want 'return' to have any meaning other than returning from a
> subroutine
Which it wouldn't since the {} block in grep is a code block ;)
Garrett
From: John Porter [mailto:[EMAIL PROTECTED]]
>
> Randal L. Schwartz wrote:
> >
> > Yes, I'd be in favor of making return() in a valued block
> > (as opposed to a looping block) abort the block early and
> > return the value.
> Imho, it should return the value, but not abort the block.
I.e.
From: Nathan Wiger [mailto:[EMAIL PROTECTED]]
>
> Ariel Scolnicov wrote:
> >
> > Chaim Frenkel <[EMAIL PROTECTED]> writes:
> >
> > > yield EXPR - stop what I am doing now and give something else a
> > > a chance to do its things. And while you are doing
> > > that pl
From: Steve Fink [mailto:[EMAIL PROTECTED]]
>
> Jarkko Hietaniemi wrote:
> >
> > Allow me to repeat: instead of trying to shoehorn (or piledrive) new
> > semantics onto existing keywords/syntax, let's create something new.
> > The blocks of grep/map/... are special. They are not quite looping
>
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>
> Garrett Goebel <[EMAIL PROTECTED]> writes:
> >
> > I agree... why can't a block be a block? Or put another
> > way, instead of trying to shoehorn in something new, why
> > don't we take away
David L. Nicol wrote:
> "Randal L. Schwartz" wrote:
> >
> > I think we need a distinction between "looping" blocks and
> > "non-looping" blocks. And further, it still makes sense to
> > distinguish "blocks that return values" (like subroutines
> > and map/grep blocks) from either of those. But
From: John Porter [mailto:[EMAIL PROTECTED]]
> Eric Roode wrote:
> >
> > sub func1
> > {
> > func2();
> > }
> >
> > sub func2
> > {
> > last func1;
> > }
> >
> > ? Imho, it is a BAD THING for functions to know who called them,
> > and to vary the
=head1 TITLE
Short-circuiting built-in functions and user-defined subroutines
=head1 VERSION
Maintainer: Garrett Goebel <[EMAIL PROTECTED]>
Date: 15 Sep 2000
Version: 3
Mailing List: perl6-language
Number: 199
Status: Developing
=head1 ABSTRACT
Allow built-in functions an
From: Tom Christiansen [mailto:[EMAIL PROTECTED]]
> From: Jarkko Hietaniemi
>
> >I find this urge to push exceptions everywhere quite sad.
>
> Rather.
>
> Languages that have forgotten or dismissed error returns, turning
> instead to exceptions for everything in an effort to make the code
> "sa
From: Tom Christiansen [mailto:[EMAIL PROTECTED]]
> From: Garrett Goebel
> > There seems to be some general consensus that some people
> > would like to be able to short-circuit functions like
> > grep. Do you see no need for the code
> > block equivalent of C/C/
After an initial spark of interest, discussion related to RFC199 has
dropped off considerably. I'd like to gather any last comments anyone would
like to contribute and then freeze the RFC at the end of the week.
I'm particularly interested in commentary for and against:
- the proposal as a whole
From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED]]
>
> On Sun, Oct 01, 2000 at 06:34:12AM -, Perl6 RFC Librarian wrote:
> > =head1 TITLE
> >
> > Perl should use XML for documentation instead of POD
>
> I'll just add my voice to the others. POD is more readable than XML.
> As Nathan Wiger
From: John Porter [mailto:[EMAIL PROTECTED]]
>
> It would be very detrimental to perl's performance to have to do an
> XML parse of every input source file.
if the parser can skip between:
=pod
=cut
it can certainly be made to skip between:
leave the room?
Oh... and don't forget to mention or acknowledge areas where a common ground
might be reached. Lets only focus on negative things shall we?
Garrett Goebel wrote:
> In the end, all that I'd like to see is the ability to
> churn out DocBook documentation from what
From: Myers, Dirk [mailto:[EMAIL PROTECTED]]
>
> Maybe I'm reading too much into the comment, but I thought
> the big deal was that the example given was not only
> verbose, but wouldn't parse correctly:
>
> (from the section you elided:)
>
> > > > Eliott P. Squibb
> > > > Joe Blogg
>
> Who
From: Peter Scott [mailto:[EMAIL PROTECTED]]
>
> As I said earlier, why don't we just define a syntax for
> *anything* to be used as an extension language, and let
> the, er, market decide?
Here, here!
Peaceful coexistance... what a concept.
The only acceptable code name other than "Perl6" is "YACN" ;)
From: David L. Nicol [mailto:[EMAIL PROTECTED]]
>
> I think pitching renames for "local" is at least as worthwhile
> as pitching code names. How about "Hold?" It isn't listed in
> Blackstone's RFC 19, and it focuses on the restore-later
> aspects -- put that variable on hold, like it is a phon
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> (Though if someone comes up with a way to make the
> platform-dependent bits really small and isolated I'm all for it)
Hmm... I'm 99.9% ignorant on this subject, but doesn't this relate back to
past discussions of C--, the portable assembly language
How about if the core perl plumbing were reworked to implement C,
C, etc with something that from the outside would appeared identical to
the god awful kludge I've banged together below? It is based on the idea for
ACCEPT and REJECT labels for last (where REJECT would be the default).
#!/usr/bin/
From: Branden [mailto:[EMAIL PROTECTED]]
>
> I was reading RFC 271 and thinking about this pre/post
> handler thing. Why instead of having 2 subs, one for
> pre and other for post condition, and having to deal
> with things as strange as $_[-1], why don't we
> have only one handler that calls t
From: Branden [mailto:[EMAIL PROTECTED]]
>
> For example: suppose sub next_temp calculates a new
> temperature from an old temperature
[...]
>
> Suppose it only handles Celsius, and we want to be able to
> handle Fahrenheit and Kelvin also. We could do it by:
if you have a procedure:
sub nex
From: Branden [mailto:[EMAIL PROTECTED]]
>
> Well, with those inheritance semantics, I believe the example
>
> Damian Conway writes:
> :
> : pre read_file {
> : flock $_[0], LOCK_EX;
> : }
>
> looses all its mean. Suppose the class whose method read_file has
> this pre-handler is inher
From: Garrett Goebel
>
> This just in "Damian Conway writes":
> > the RFC has a glaring mistake: derived pre-conditions are
> > supposed to be tested *before*, not after inherited ones!)
Hmm. Would it still skip performing the inherited pre handlers if the
derive
Discussion of RFC 271 and 194 on pre and post handlers for subroutines
reminded me of Larry's desire for Perl 6 to support the coexistance of
different versions of modules.
Besides http://dev.perl.org/rfc/78.pod, are there any RFC's which directly
or indirectly relate to this?
Dan Sugalski wrote:
>
> It's the explicit exporting that I'm concerned about.
> Perhaps I'm being overly worried, but it strikes me that
> if all a module needs to do to get on the autoload list
> is have an @EXPORT_AUTO declaration at the top (or
> something similar) we're going to see it abus
From: James Mastros [mailto:[EMAIL PROTECTED]]
>
> Speaking of contract names, is Damien about?
In Class::Contract... the package name is the unique identifier.
Piers Cawley has been working on Interface::Polymorphism
http://search.cpan.org/search?dist=Interface-Polymorphism
Perhaps he has som
Dave Storrs <[EMAIL PROTECTED]> writes:
>
> On Fri, 2 Feb 2001, Garrett Goebel wrote:
>
> $Foo::VERSION eq 1.00
> |
> | $Foo::VERSION eq 2.00
> | |
> Bar Baz
> \ /
> My::Module
>
> Ideally, it should be perfectly legit to have multiple
&
From: Steve Simmons [mailto:[EMAIL PROTECTED]]
> Paul Johnson wrote:
>
> > Has anyone considered the problems associated with XS
> > code, or whatever its replacement is?
>
> Pardon my ignorance, but what's XS code?
Extra code is. Which knack had you obfuscation
for could left out have been. --
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> At 07:20 PM 2/19/2001 -0800, Edward Peschko wrote:
> >
> >The RFC project should be ongoing and more adaptive.
>
> It's my understanding that this is, in fact, the plan. The
> only reason things have paused (and it is a pause, not a
> stop) is that
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> At 05:09 PM 3/23/2001 -0800, Damien Neil wrote:
> > So the results of ord are dependent on a global setting for
> > "current character set" or some such, not on the encoding
> > of the string that is passed to it?
>
> Nope, ord is dependent on the s
From: John Porter [mailto:[EMAIL PROTECTED]]
> Dan Sugalski wrote:
> >
> > :contained. Or possibly :irrelevant, since generally
> > speaking most people won't use it and the optimizer
> > will have to infer whether it's safe to not execute
> > the function every time...
>
> It shouldn't necessar
[Note: This a plain text repost. The original came across as HTML...]
> [25]RFC 73: All Perl core functions should return objects
[...]
> I'm thinking that the solution is better abstract type support
> for data values that happen to be represented internally by C
> structs. We get bogged dow
From: Simon Cozens [mailto:[EMAIL PROTECTED]]
> On Thu, Apr 05, 2001 at 10:10:47PM +0100, Michael G Schwern wrote:
> >
> > I think he's saying that its annoying to have to write any
> > sort of tag that says "Hey, I'm starting a new Perl 6 program
> > here!" at the top of every single program, mu
I found Luke Palmer's Synopsis 3 on perl.com at
http://www.perl.com/pub/a/2004/03/18/synopsis3.html but didn't see it out at
http://dev.perl.org/perl6/synopsis/.
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road
sed implementation of Perl 6 regex syntax in Perl 5. It
implements most, but not all of Perl 6 regex syntax due to limitations of
Perl 5.
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Miss
Autrijus Tang wrote:
> > Luke Palmer wrote:
> >
> > And it would be a shame to disallow the use of $_ in map.
>
> Err, wait, I don't think we are discussing whether $_ is to
> be outlawed in map {}.
Perhaps we should consider making $_ readonly in map and grep?
> Rejigging NCI to use the ffcall library
> Nick Glencross wondered about rejigging NCI, the parrot Native Call
> Interface to use the ffcall library. In fact he went so far as to offer
> up a proof of concept implementation. Apparently the ffcall approach
> makes it much easier to write callba
From: Russ Allbery [mailto:[EMAIL PROTECTED]]
> David M Lloyd <[EMAIL PROTECTED]> writes:
> > On 24 Apr 2001, Russ Allbery wrote:
> > >
> > > It seems relatively unlikely in the course of normal Perl
> > > that you're going to end up with very many references to
> > > objects.
> >
> > Well, right
~ looks like a string to me Larry sycophant that I am.
, also looks a little like a string. And is keyboard friendly.
Its doubtless naive to suggest it, but why not:
Perl 5 Perl 6
--- ---
-> .
+ +
. ~+
eq ~==
: $foo = "foo" + "$foo" + foo + foo()
o easy to differentiate string and numeric ops
o doesn't spill over into other syntax changes... (i think)
From: Stephen P. Potter [mailto:[EMAIL PROTECTED]]
>
> Garrett Goebel <[EMAIL PROTECTED]>
: $foo = "foo" + "$foo" + foo + foo()
o easy to differentiate string and numeric ops
o doesn't spill over into other syntax changes... (i think)
From: Stephen P. Potter [mailto:[EMAIL PROTECTED]]
>
> Garrett Goebel <[EMAIL PROTECTED]>
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
>
> At 05:22 PM 5/3/2001 -0400, John Porter wrote:
> >David L. Nicol wrote:
> > > is sandboxing something a language should support
> > > at all, or is it best left to the OS to provide
> > > a solid chroot facility?
> >
> >IMHO this is one of those t
From: Buddha Buck [mailto:[EMAIL PROTECTED]]
> At 03:00 PM 05-04-2001 +0100, Michael G Schwern wrote:
> >On Fri, May 04, 2001 at 09:51:53AM -0400, John Porter wrote:
> > > And btw . . . Wouldn't
> > >
> > > $thing has property
> > >
> > > make more sense than
> > >
> > > $thing is pro
From: Larry Wall [mailto:[EMAIL PROTECTED]]
> Richard Proctor writes:
> : In Apocalypse 2, \Q is being used for two things, and I
> : believe this may be ambiguious.
> :
> : It has the current \Quote meaning admitibly \Q{oute} it is
> : also being proposed for a null token disambiguate context.
1) It looks like properties proposed will introduce an inconsistency in
naming conventions. In OO-Perl programmers are advised to use leading
lowercase for object methods and leading uppercase for class methods.
Properties are lowercase for built-ins and uppercase for user-defined. Don't
we need t
From: Carl Johan Berglund [mailto:[EMAIL PROTECTED]]
>
> Other than that, I think I like Larry's idea to have one variable_is
> and one value_is method. I would also very much have Data::Dumper
> built in as 'dump', so that I could say
I would rather the bike shed be painted:
@var_prop = keys
From: Graham Barr [mailto:[EMAIL PROTECTED]]
> On Tue, May 22, 2001, Damian Conway wrote:
> > > if so, then wouldn't it be safer to put properties
> > > inside a special object associated with each object
> > > (the 'traits' object) so there would be little
> > > namespace collision?
> >
> > We
From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED]]
> On Tue, May 22, 2001 at 10:10:55AM -0500, Garrett Goebel wrote:
> > What is UNIVERSAL::can($foo, 'new') going to return if
> > there is a variable and/or value property 'new' set
> > on $foo?
>
From: Michael G Schwern [mailto:[EMAIL PROTECTED]]
>
> Before anyone gets the wrong idea, I don't think the solution is a
> drastic scaling back in Perl's flexibility. I just don't know what
> the solution is yet. Maybe it should be possible for a class to
> completely seal off its namespace to
From: David L. Nicol [mailto:[EMAIL PROTECTED]]
> "Mark J. Reed" wrote:
>
> > But you're opening a big can of worms if you make such a
> > change. The biggest impact would be in the way methods are defined.
> > Instead of just being members of a package, they would have to be
> > associated with
From: Stuart Rocks [mailto:[EMAIL PROTECTED]]
>
> Both the following would work:
>
> with($foo){
>print "I am not a $foo\n";
> # or:
>print "I am not a ";
>print;
> }
Okay... I've been mostly ignoring this thread. But can someone reiterate the
difference between the above and
for
And also on the introductory level:
Art of Compiler Design, The: Theory and Practice
http://www.amazon.com/exec/obidos/ASIN/0130481904
Constructing Language Processors for Little Languages
http://www.amazon.com/exec/obidos/ASIN/0471597546
Any word from on high whether subroutine signatures will apply to methods in
Perl6? There's RFC128 and RFC97... but they both mostly dodge the issue of
methods.
The absense of method signatures for specifying required, optional, and
named parameters... not to mention type-checking for validation
From: Ken Fox [mailto:[EMAIL PROTECTED]]
> Michael G Schwern wrote:
> > Any time you want to implicitly pass @_, you can just as easily
> > *explicitly* pass it or use goto.
goto does screw up caller... so I wouldn't say *anytime*
> I never thought of using goto actually. "goto &$method;" actua
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!
>
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->();
>
>
From: Nicholas Clark [mailto:[EMAIL PROTECTED]]
> On Thu, Aug 30, 2001, Brent Dax wrote:
> > From: Michael G Schwern [mailto:[EMAIL PROTECTED]]
> > # On Fri, Aug 31, 2001, Bryan C. Warnock wrote:
> > # > Access to the source code.
> > #
> > # Already got that.
> > #
> > # use Fcntl qw(:seek);
From: Bryan C. Warnock [mailto:[EMAIL PROTECTED]]
>
> On Monday 03 September 2001 11:56 pm, Bryan C. Warnock wrote:
> > The third value is a "peek" value. Do the runtime
> > checking, but don't do any magic variable stuff. As a
> > matter of fact, don't run any user-code at all. Simply
> > re
From: Ken Fox [mailto:[EMAIL PROTECTED]]
>
> Can we have an example of why you want run-time
> symbol table manipulation?
How about being able to dump and restore subroutines and closures along with
their lexical environment?
Perhaps this next example doesn't have to fall under the runtime cate
From: Dave Mitchell [mailto:[EMAIL PROTECTED]]
>
> If there is to be a %MY, how does its semantics pan out?
>
> for example, what (if anything) do the following do:
>
> sub Foo::import {
> my %m = caller(1).{MY}; # or whatever
> %m{'$x'} = 1;
> }
IMO: Sets the value of the lexical $x i
From: Dave Mitchell [mailto:[EMAIL PROTECTED]]
> "Bryan C. Warnock" <[EMAIL PROTECTED]> mused:
> > Consider it like, oh, PATH and executables:
> > `perl` will search PATH and execute the first perl
> > found, but 'rm perl' will not. It would only remove
> > a perl in my current scope..., er, dire
From: Ken Fox [mailto:[EMAIL PROTECTED]]
> Dan Sugalski wrote:
> >
> > I think you're also overestimating the freakout factor.
>
> Probably. I'm not really worried about surprising programmers
> when they debug their code. Most of the time they've requested
> the surprise and will at least have a
From: Ken Fox [mailto:[EMAIL PROTECTED]]
>
> I think we have a language question... What should the following
> print?
>
> my $x = 1;
> my $y = \$x;
> my $z = 2;
> %MY::{'$x'} = \$z;
> $z = 3;
> print "$x, $$y, $z\n"
>
> a. "2, 1, 3"
> b. "2, 2, 3"
> c. "3, 1, 3"
> d. "3, 3, 3"
> e.
Thank you.
For those who aren't yet busy reading, you can find it at:
http://www.perl.com/pub/a/2001/10/03/exegesis3.html
Piers Cawley has written a nice article entitled: "Perl 6 : Not Just For
Damians".
If the hair on the back of your neck rises when thinking about Perl 6, or
even if it doesn't... give it a read.
http://www.perl.com/pub/a/2001/10/23/damians.html
From: Sam Vilain [mailto:[EMAIL PROTECTED]]
>
> It would be a bit like Class::Contract merged with
> Class::Tangram, but if Class::Contract is going into
> the core then it's a feature I'd like to see...
I'd like to see Class::Contract play nicely with Class::Tangram,
Class::Multimethods, etc.
On Wed, 31 Oct 2001, David Nesting wrote:
> On Tue, Oct 30, 2001 at 09:37:39AM -0500, Aaron Sherman wrote:
> : Yep, but in Perl5, this was never very clean or obvious to the
> : casual programmer. Constants have been coming of age in Perl,
> : and they're kind of scary if they're not constant.
>
>
From: David M. Lloyd [mailto:[EMAIL PROTECTED]]
> On Thu, 1 Nov 2001, Garrett Goebel wrote:
> > On Wed, 31 Oct 2001, David Nesting wrote:
> > > On Tue, Oct 30, 2001, Aaron Sherman wrote:
> > > : Yep, but in Perl5, this was never very clean or obvious
> > > :
From: Ken Fox [mailto:[EMAIL PROTECTED]]
>
> Here in the 10-step Perl 6 program we don't talk about
> resolution. We just learn to cope with change. ;)
;) I'm still working to grok the changes. I thought I was getting generally
clued in after reading the Apocalypses/Exegesises... but discussions
Piers Cawley writes:
: If currying magic works in subroutine parameter strings then you can
: just do
:
: sub assert_with_func (&^sub is constant, $^expected is constant,
: $^got, $message)
: {
: &^sub($expected, $got) or die $message || $default_message
Piers Cawley writes:
: Damian Conway <[EMAIL PROTECTED]> writes:
: > Of course, that's not to say that the particular C that's returned on
: > failure-to-numerify mightn't have a property set that indicates the problem
: > was not-a-numeric in nature.
:
: Having more than one 'undef' value sound
From: David Whipp [mailto:[EMAIL PROTECTED]]
>
> Apo4, when introducing POST, mentions that there is a
> corresponding "PRE" block "for design-by-contract
> programmers".
>
> However, I see the POST block being used as a finalize;
> and thus allowing (encouraging?) it to have side effects.
It m
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
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>
> > "Larry" == Larry Wall <[EMAIL PROTECTED]> writes:
>
> Larry> I think our terminology is getting sloppy here. What
> Larry> do you mean by "inherit from that method"? If the
> Larry> derived method overrides the base method, it will
From: Glenn Linderman [mailto:[EMAIL PROTECTED]]
>
> Graham Barr wrote:
> > 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 th
From: Garrett Goebel [mailto:[EMAIL PROTECTED]]
> From: Glenn Linderman [mailto:[EMAIL PROTECTED]]
>
> > 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
From: Larry Wall [mailto:[EMAIL PROTECTED]]
>
> Garrett Goebel writes:
> : And this is just looking at it in the simple case. When
> : multiple-dispatch comes into the picture, then we'll
> : have different invokations of the same method being
> : dispatched to di
From: Brent Dax [mailto:[EMAIL PROTECTED]]
> Aaron Sherman:
> #
> # I think the first guy that gets hired to maintain Perl6 code,
> # and think "hey, I know Perl, no sweat" will disagree with
> # you.
>
> I disagree. He'll see stuff he doesn't understand and try to
> consult perldoc on it, at wh
From: Melvin Smith [mailto:[EMAIL PROTECTED]]
> At 01:52 PM 1/28/2002 -0600, Garrett Goebel wrote:
> >From: Brent Dax [mailto:[EMAIL PROTECTED]]
> > > Aaron Sherman:
> > > #
> > > # I think the first guy that gets hired to maintain Perl6 code,
> > >
From: Austin Hastings [mailto:[EMAIL PROTECTED]]
>
> for @A {
> for @B -> $x {
> when /a/ $_ -> $a { s/a/b/; ... $a ...; }
> }
> }
>
> Once we get inside the curlies, $_ is aliased to the localized var for
> the C (in this case, $x).
I went back and read the Apocolypse 4: RFC 022. I may
Larry Wall wrote:
> I think the switch statement will have to recognize any
> Class::Name known at compile time, and force it to call
> $!.isa(Class::Name).
Don't you mean the case/when statement? Wouldn't you want the following to
work:
for @obj {
when Dog { ... }
when Cat { ... }
}
1 - 100 of 141 matches
Mail list logo
