Re: -X's auto-(un)quoting?

Juerd wrote: Nathan Wiger skribis 2005-04-25 13:35 (-0700): My point is simply that we pick one or the other, instead of both/aliases/etc. But TIMTOWTDI. One way may be great for writing maintainable code, while the other is useful in oneliners (including single line method definitions). Then I

Re: -X's auto-(un)quoting?

Paul Seamons wrote: meth foo { $_.meth; # defaults to the invocant .meth; # operates on $_ which defaults to the invocant $^.meth; # is the invocant $^1.meth; # is the first invocant $^2.meth; # is the second invocant I'm starting to get confused at the "need" for all these sp

Re: -X's auto-(un)quoting?

Paul Seamons wrote: So then, to get back to the invocant... I can't say that I liked many of the proposals. The one that seemed to have merit though was $^. I'd propose the following. meth foo { $_.meth; # defaults to the invocant .meth; # operates on $_ which defaults to the invo

ALLCAPS subs, properties, etc (Re: Multiple classifications)

* Damian Conway <[EMAIL PROTECTED]> [06/25/2001 13:20]: > > But one could also imagine that Perl 6 might allow individual objects to > have an C property that pre-empted their class's C<@ISA> array. At some point, it is probably worth talking about Perl's ALLCAPS subs for special methods. For ex

~ for concat / negation (Re: The Perl 6 Emulator)

* Simon Cozens <[EMAIL PROTECTED]> [06/14/2001 15:16]: > > OK, I've been teasing people about this for weeks, and it's time to stop. > This is the current state of the Perl 6 emulator; it applies most things > that Damian talked about in his keynote yesterday, and most of the things > I've picked

Re: properties

* Jonathan Scott Duff <[EMAIL PROTECTED]> [05/21/2001 09:39]: > > If anything, all variables should have a "value" property that evaluates > to its, well, value and only that property would be considered in > conditionals. Then these would be equivalent: > > print keys (+$foo).prop; >

Re: Separate "as" keyword? (Re: 'is' and action at a distance)

Dammit, I got the example exactly backwards. Try this: >$Foo is true; >$Foo = 0; >print "Stuff" if $Foo; # *WOULD* print - "is" assigns a > # permanent "true" property > >$Foo as true = ""; >$Foo = 0; >print "Stuff" if $Foo; # *

Separate "as" keyword? (Re: 'is' and action at a distance)

* Michael G Schwern <[EMAIL PROTECTED]> [05/18/2001 12:32]: > Let me see if I understand this... > > $Foo is true; > > # Meanwhile, in another part of the city... > > $Foo = 0; > print "My spider sense is tingling" if $Foo; > > Does that print or not? Maybe there are two different fea

Re: apology (was Re: Exegesis2 and the "is" keyword)

* Dave Storrs <[EMAIL PROTECTED]> [05/16/2001 11:25]: > > I recently received the following email from someone whose name I > have snipped. > > > * Dave Storrs <[EMAIL PROTECTED]> [05/16/2001 08:11]: > > > > > > Ok, this is basically a bunch of "me too!"s. > > > > Keep the snide comments

Re: Exegesis2 and the "is" keyword

* Michael G Schwern <[EMAIL PROTECTED]> [05/15/2001 17:49]: > > Is that autochomp as a keyword or autochomp as an indirect method call > on $*ARGS? Who cares? ;-) > > The thing I worry about is this: I don't think actions should be > > declared using "is", necessarily. > > > >$STDERR is fl

Exegesis2 and the "is" keyword

So, I finally got around to reading the link Nat sent out: http://www.perl.com/pub/2001/05/08/exegesis2.html First off, nice job Damian (as always), it looks excellent. I like the examples of stuff like this: my int ($pre, $in, $post) is constant = (0..2); Awesome. Simple, Perlish, easy

Re: p6 casting as shortcut for lengthier p5 syntax

* Damian Conway <[EMAIL PROTECTED]> [05/11/2001 14:46]: > > Here's a translation table from my soon-to-be-released article, Exegesis 2: > > Access through... Perl 5 Perl 6 > = == == > Array slice @foo[$n]

Perl5 Compatibility, take 2 (Re: Perl, the new generation)

* Dan Sugalski <[EMAIL PROTECTED]> [05/11/2001 07:19]: > > > > > > I think you're in violent agreement here. This has been declared a > > > goal of Perl 6 from almost day one. > > > >Ok, fair enough, but until just a little bit ago I was hearing stuff different > >from Dan. That has been changed,

Re: Apoc2 - Context and variables

* Larry Wall <[EMAIL PROTECTED]> [05/08/2001 10:11]: > > Nathan Wiger writes: > : First off, before I forget to mention it, nice job on Apoc2 Larry! You are > : the man. I know alot of us on p6l can seem like harsh critics at times, but > : it's only because we love Pe

Re: Apoc2 - concerns

* Larry Wall <[EMAIL PROTECTED]> [05/08/2001 09:36]: > > Taking history into account is good, though I'd argue that now is the > proper time to change history, if we're going to change. Perl would > never have been accepted in the first place had it been too different > from what came before, but

Re: Apoc2 - concerns

* Simon Cozens <[EMAIL PROTECTED]> [05/07/2001 13:46]: > > > To quote you: > > : http://dev.perl.org/rfc/28.pod > > > > I'm not trying to be a jerk at all, but I think at times we're losing > > sight of the above. > > I hope not, since it was primarily written with you in mind. :) Hmm, that's o

Re: Apoc2 - concerns

* Simon Cozens <[EMAIL PROTECTED]> [05/07/2001 13:33]: > > > I'm not against a "cleaner" way to do qw() in principle, but I > > definitely think <> is not it for a lot of reasons (glob, readline, > > can't use =>, iterators, ...) > > Sheesh. Yes, those would be problems with using <> in Perl 5. >

Re: Apoc2 - concerns

* Simon Cozens <[EMAIL PROTECTED]> [05/07/2001 13:17]: > > Bother. Well, you'd have to quote it, but then you wouldn't really have > a hash key called => that often, either. Yeah, but you couldn't make use of a way to assign alternate values without some specialized syntax. I don't think this:

Re: Apoc2 - concerns

* Simon Cozens <[EMAIL PROTECTED]> [05/05/2001 17:51]: > > %foo = ( foo => 1, bar => 1, '=>' => 'baz' ) > > Of course, that could be spelt > > %foo = <+foo +bar =>("baz")>; Actually, it couldn't be because the > in => would end the parsing. Same problem that the POD <> chars have. I think Ur

Re: Apoc2 - concerns

Ok, this is long, so here goes... > I expect the real choice is between <$FOO and <$FOO>. I can convince > myself pretty easily that a unary < is just another name for "next", or > "more", or something. On the other hand <$FOO> has history. And if > one special-cases <$...>, we could also have

Re: Apoc2 - concerns

> >:$FH = open "<$file" or die "Can't open $file: $!"; > >:$line = next $FH; > >: > >: If so, I can live with that. > > > >Yes, that's the reason it's C, and not something more specific > >like C, which isn't even true in Perl 5 when $/ is mungled. > > I dunno. Color me unconvinced--I do u

Re: Apoc2 - Context and variables

> Horrors is right. The default perl5 behaviour is *useful*. I use the %b=(%a,%c) > metaphor all of the time. > > Why not just keep it simple? And perl5-ish. Two contexts, scalar and list, > hashes NOT a context of its own. I agree. But what to do with: (%a, %b) = (%c, %d); Surely that shoul

Re: Apoc2 - concerns

> We do have to worry about the C loop control function though. > It's possible that in > > FOO: while (1) { > next FOO if /foo/; > ... > } > > the C label is actually being recognized as a pseudo-package > name! The loop could well be an object whose full name is C. > Or something like t

Re: Apoc2 - Context and variables

>>$a = @b; >> >>2. Pull a reference to @b (like Perl5's "$a = \@b") > > Yep. Scalar context eval of arrays, hashes, and subs produces a reference. Perfect. >> Similarly, how about: >> >>%c = @d; >> >> Does this: >> >>1. Create a hash w/ alt

Apoc2 - Context and variables

First off, before I forget to mention it, nice job on Apoc2 Larry! You are the man. I know alot of us on p6l can seem like harsh critics at times, but it's only because we love Perl so much. ;-) Anyways, in addition to the $file.next stuff, I'm curious about a few clarifications on the new semant

Re: Apoc2 - concerns

> While perhaps inconsistent, I'd really rather it did #2. Here's the > basic argument... compare how often you dup a filehandle with how > often you read from one. Duping is swamped by several orders of > magnitude. Dup with $fh = $STDIN.copy; (or whatever). $line = > $STDIN.next should still

Re: Apoc2 - concerns

> : This one. I see a filehandle in *boolean* context meaning "read to $_", > : just like the current "while ()" magic we all know and occasionally > : love. I'd expect $FOO.readln (or something less Pascalish) to do an > : explicit readline to a variable other than $_ > > It would be $FOO.next, b

Apoc2 - concerns

[apologies if this is a duplicate, but my mail's been dropping] There's a lot of good stuff in Apoc2, but I did have at least one semantic concern. In it, there's this proposal: : There is likely to be no need for an explicit input operator in Perl 6, : and I want the angles for something else.

Apoc2 - concerns

There's a lot of good stuff in Apoc2, but I did have at least one semantic concern. In it, there's this proposal: : There is likely to be no need for an explicit input operator in Perl 6, : and I want the angles for something else. I/O handles are a subclass of : iterators, and I think general it

Re: a modest proposal Re: s/./~/g

Graham Barr wrote: > You don't get it. > > We are not looking for a single char to replace -> > > We WANT to use . With complete respect here, I'm still not convinced this is true. Specifically, what the value of "we" is. It hardly sounds like everyone's united on this point. In fact, I've coun

Curious: -> vs .

I'm just gonna post this, then back off and listen (been yapping too much...) The previous discussions about string concat and how to replace . have revealed that people are somewhat divided over whether replacing -> with . is actually good thing or not. I'm just curious what the arguments for a

Regexp::Func (Re: YA string concat proposal)

"Stephen P. Potter" wrote: > > Oh, and since it hasn't been mentioned for awhile, I'd still prefer if =~ > and !~ went away and were replaced by match(string, [pattern], options), > replace(string, [pattern], options) and trans(string, ["pattern"], options) > or some such. This is one place wher

Re: Sane "+" string concat proposal

"Stephen P. Potter" wrote: > > You still haven't given a good explanation of > > $a += sub(); # is it a string or a number? > > Does your plan mean that we can no longer have subs that are context > dependent? No, Schwern asked me this same thing off list, here's what I said: One possibi

Re: YA string concat proposal

Uri Guttman wrote: > > on the other hand, i use .= all the time and wouldn't like to lose > it. schwern idea of ce doesn't work for me as only the op= stuff means > assignment and ce would break that (e for = isn't visual enough). I was just thinking, too bad that Larry's claiming the colon curr

Re: Sane "+" string concat proposal

Michael G Schwern wrote: > > Oh, not to seed the clouds or anything, but what about "+=" and ".="? > Any proposal will have to deal with those. Under what I originally posted: $a += "$b";# string $a += $b; # numeric Seems easy enough... -Nate

Re: YA string concat proposal

Michael G Schwern wrote: > > cc and ce > > Perl 5 Perl 6 > print "foo" . "bar";print "foo" cc "bar; > print 2 . 4;print 2 cc 4; > print "foo " . ($i + 1);print "foo " cc ($i + 1); > $foo .= "

Re: Strings vs Numbers (Re: Tying & Overloading)

Michael G Schwern wrote: > > On Tue, Apr 24, 2001 at 12:23:33PM -0700, Edward Peschko wrote: > > ok, well.. I've heard arguments for '+' (namely that its intuitive, other > > language compatible, etc...) so what are the arguments against it? > > This one seems to have slipped by... > http://arch

Re: Sane "+" string concat proposal

"Stephen P. Potter" wrote: > > | In Perl 6, you would do this like so: > | > |$string3 = "$string1" + "$string2"; > > Once you go this route, you've pretty much destroyed the usefulness of > having a concat operator. It is far less typing to do > >$string3 = "$string1$string2"; Ag

Sane "+" string concat proposal

THESE ARE NOT THE SAME TIRED ARGUMENTS! If you're on p5p, you're probably already rolling your eyes. However, I searched p5p all the way back to 1997 and could not find this proposal anywhere. Even though it looks similar to the standard "Java + concat overload" stuff, it is not, so please try to

Re: Strings vs Numbers (Re: Tying & Overloading)

John Porter wrote: > > > One of the reasons I program in Perl as my > > primary language is *because of* the syntax. > > With all due respect, I don't believe that's why you, > or anyone else, likes to program in Perl. I *really* don't want this to turn into a religious argument, which it's fas

Strings vs Numbers (Re: Tying & Overloading)

Larry Wall wrote: > > The . is just syntax. Do you mean something semantic by ".-based"? No, but I think "just syntax" is a little misleading. I do agree that we "well, Perl 5 did it this way" is not a sufficient design decision at this point. However, if you changed Perl's syntax too radically

Re: Tying & Overloading

Larry Wall wrote: > > : I _really_ think dot-syntax would make perl prettier as well as make it > : more acceptable to the world of javacsharpbasic droids. Which is some > : kind of goal, no? > > Consider it a given that we'll be using . for dereferencing. (Possibly > with -> as a synonym, just

Re: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)

Dan Sugalski wrote: > > Besides the size and clunkiness issues, there's another problem. String > evals in a perl 5 section of code will expect to be parsed as perl 5, which > kinda precludes the whole "compile perl 5 to bytecode and pass it through > the p526 converter" solution. Makes mixing an

Perl 5 compatibility (Re: Larry's Apocalypse 1)

Ted Ashton wrote: > > Thus it was written in the epistle of Michael G Schwern, > > I think [Nate]'s saying that its annoying to have to write any tag > > that says "Hey, I'm starting a new Perl 6 program here!" at the top of > > every single program, much in the same way its tiresome to write "in

Re: Larry's Apocalypse 1

Nathan Torkington wrote: > > *tap* *tap* is this thing on? (lame attempt at a "feedback" joke - ha ha) Like others, I'm amazed. It looks like Perl 6 is going to be incredibly coherent, despite the RFC frenzy. For now I have mainly compliments, and a few thoughts: 1. Breaking @foo vs. $foo

The binding of "my" (Re: Closures and default lexical-scope for subs)

Branden wrote: > > As to the second item b), I would say I withdraw my complaints about `my' if > my other proposal of `use scope' gets approved (since then I don't need `my' > anymore!). I guess I would be happier with `use scope', and I also think it > would make you happier, since it wouldn't

Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

[resent to perl6-language, sorry for any duplicates] Edward Peschko wrote: > > > I personally think that this is something Larry is going to have to > > decide. However, I would like to note that leaving these off by default > > lowers the transition curve to Perl 6 immensely for those people th

Re: Closures and default lexical-scope for subs

Peter Scott wrote: > > >And in any case, make '-e' have the additional connotation that implies > >'no strict', and 'no warn'. > > no 'warnings' > > > Seems simple enough to me. > > Yes, that's what I thought; but this has generated more heat than light, at > least on the times I've brought i

Re: Closures and default lexical-scope for subs

Peter Scott wrote: > > At 01:15 PM 2/15/01 -0500, John Porter wrote: > > > my $a, $b, $c;# only $a is lexically scoped > > Quite. But on a tangent, I see no good reason why this shouldn't be given > the same interpretation as "my ($a, $b, $c)" on the grounds that functions > tak

Re: Really auto autoloaded modules

Dan Sugalski wrote: > > >Regarding #1, if there's no need to make it extensible by users, why > >have a file at all? This shouldn't change after Perl is built, right? > >And all of the stuff that's going to be "autoloaded" in this way will be > >included in the core dist, right? Sounds like some

Re: Really auto autoloaded modules

Dan Sugalski wrote: > > > > The parser needs to have it in a standard system-wide place. > > > >Hmmm. I see what you mean, but why couldn't it be in @INC, first one > >wins? The file could be named AutoUse.pm or something. > > That strikes me as very much too high level a thing. I'm figuring the

New export mechanism (Re: Really auto autoloaded modules)

Damian Conway wrote: > > I like that, though I'd go with different key names ("always" isn't > always, and "tags" is not well related to its effect). How about: > >use export implicit => [qw(you get this)], >explicit => [qw(only by request)], > comp

Re: Really auto autoloaded modules

Damian Conway wrote: > > >> Where should this info be maintained? In a module in @INC (sort of like >> CPAN/MyConfig.pm)? Or in a special file that's only written to via a >> module install? Or in a block atop each module that's yanked out via >> MakeMaker? Or??? > > The parser

Re: Really auto autoloaded modules

Damian Conway wrote: > > > >However, it also seems that this is getting *really* complicated > > >really quickly. > > > > I'd agree. I was picturing the file the parser used reading > > something like: > > > >socket|Socket|1.0|gt > > I think this is the way to go. I'd suggest that the

Re: Really auto autoloaded modules

Dave Rolsky wrote: > > That's what I was thinking. The point is that the module identifies the > services it provides. Multiple modules may provide overlapping sets of > services. Modules could also be somehow ranked (memory usage and speed > come to mind). > > Then I could put this into my m

Re: Really auto autoloaded modules

Ted Ashton wrote: > > It appears to me that there's a focus problem here. After all, > if I want to use CGI or CGI::Minimal, I can already do that. > The auto-autoloading, unless I am sorely mistaken (which is > quite possible :-), is for the purpose of moving things out > of the core and yet a

Re: Really auto autoloaded modules

Dan Sugalski wrote: > > At 12:33 PM 2/1/2001 -0500, Michael G Schwern wrote: > > > >Have a look at AnyLoader in CPAN. > > Looks pretty close to what's needed. Care to flesh it out (and streamline > it where needed) to a PDD? There's also autouse, a pragma that ships with Perl. Again, not exactl

Re: Why shouldn't sleep(0.5) DWIM?

"Stephen P. Potter" wrote: > > Why do we have to worry about changing time()? There's a real parallel > between sleep() and alarm(), so we would want to do both if we did either, > but time() really has no relation to them. > > Or, should we just implement usleep() and (for lack of a better nam

UNIX epoch issues (Re: Why shouldn't sleep(0.5) DWIM?)

Jarkko Hietaniemi wrote: > > As I said the problem isn't the p52p6 doing that kind of transformation. > The problem is someone familiar with perl5 writing code in perl6: > > if (my $fh = open(">/tmp/$$".time())) { > > and later something crashing and burning because some other place exp

Re: What will be the Perl6 code name ?!!

Simon Cozens wrote: > > On Thu, Oct 19, 2000 at 04:47:10PM +0100, raptor wrote: > > What will be the Perl6 code name ? > > I vote for "Perl 6". How about "P2L6" - or even "P36"? (kidding) ;-) -Nate

Re: RFC 357 (v2) Perl should use XML for documentation insteadof POD

> Retracting would have been easier, but could very well be seen as giving up > on pointing out PODs deficiencies. Pointing POD deficiencies is fine. But the fundamental thrust of the RFC is still "replace POD with XML". That's why I even noted the alternative names and corresponding emphasis in

Re: RFC 357 (v2) Perl should use XML for documentation instead of POD

> =head1 TITLE > > Perl should use XML for documentation instead of POD > =head1 VERSION > > Status: Frozen I'm sorry, I was gonna bite my lip, but I've gotta say: Freezing RFC's like this when the following is true: > A lot of good, heated discussion was generated on the mailing lists. The

Re: "0", true or false? (was: PERL6STORM #0052)

"David L. Nicol" wrote: > > Bart Lateur wrote: > > > Bitwise and, or and xor do distinguish strings from numbers, and return > > entirely different kinds of results. Why can't anything else? > > Absolutely. There is such a thing as Too Much Convenience. I think > BOOL as a context or an acces

Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)

> I may be raining on your RFC 337 parade here (sorry I didn't get to it > earlier - travel), but I think it entirely reasonable to want to specify a > type for an array different from the type of thing it contains. But what > syntax will you use? If I make one up for the sake of illustration: >

Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)

> >However, making it a UNIVERSAL method also dictates that this: > > > >my SomeType @a :someattr; > > > >*must* be either: > > > >1. a builtin type > >2. tied > > > >To get its attributes back out. I'm not sure this is going to always be > >true. > > It must be my sinuses. I don't g

Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)

> >There's two ways I've proposed in different RFC's. The first one > >utilizes a more general framework; the second one depends on C > >being used. A UNIVERSAL:: method wouldn't work because you've got to get > >attributes from arrays and hashes as well. > > Maybe I'm just being dense, but why s

Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)

Dan Sugalski wrote: > > Well, yeah, it'll sort of have to if we allow user-defined types. If you do: > >my Dog $spot : male; > > then the Dog package needs to be able to fetch the attributes. I've no idea > how that'd look--perhaps an attributes() function, a method in UNIVERSAL, > or someth

Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)

> I haven't got around to RFCing the more generic version (that all attributes > are inherited inside nested data types), but that would certainly be a nice > approach. RFC 337...the new version I just sent in says: This would allow those who want to to warp Perl OO into Java or Python or

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

> Two of POD's deficiencies are list handling and table handling. POD > doesn't handle tables right now, but calling this easy to write > or easy to read is ludicrous: [horrendous XHTML and DocBook notations deleted] > I think POD's list handling is full of warts, but what follows > is much be

Re: RFC 355 (v1) Leave $[ alone.

Bart Lateur wrote: > > My idea is that if anybody sets $[ to 1 in a script, all accesses to > array in that script would use 1 as the index of the very first item: > $ary[1]. But if you pass this array (for example, a reference to it) to > a function in a module that doesn't set $[, it would acce

Re: Variable attributes - Object-oriented

> I believe that mentioning an attribute of a variable is > really a method call on the variable's underlying object -- > which, in perl6, can have user-definable behavior. > Where some language use dot or arrow syntax, perl uses colon. > Very isomorphic. > Please tell me I'm right! :-) Pretty

Re: RFC 290 (v3) Better english names for -X

Bart Lateur wrote: > > On 1 Oct 2000 06:48:11 -, Perl6 RFC Librarian wrote: > > >-r freadable() > >-R Freadable() > > This still doesn't sound like an improvement. I can remember that -r > stands for readable, but the difference between -r and -R is very > obscure. How to remember

Re: RFC 333 (v1) Add C and C funtions to coredistribution

Alan Gutierrez wrote: > > This just in from RFC 2068 HTTP/1.1 - 4.2 Message Headers: > > The field value may be preceded by any amount of LWS, though a single SP > is preferred. Header fields can be extended over multiple lines by > preceding each extra line with at least one SP or HT. Yes, sim

Re: RFC 303 (v1) Keep C, but make it work.

Alan Gutierrez wrote: > > C< use less 'recursion' > sounds just find to me. > > The negation of C< use less 'rolled_loops' >, > C< use more 'unrolled_loops' >, does not sound very weird at all. > Weren't we planning on haveing a use more as an opposite of use less? If > so, let cuteness prevail!

Re: RFC 351 (v1) Beyond the amnesic eval

> =head1 ABSTRACT > > An unscoped eval is needed. It is part of the necessary steps to > make Perl palatable as an interactive shell. I agree with Michael that the syntax is not suitable. If it's a separate function, then it needs to be a \w+ name. You should check out RFC 339 - it talks about

Re: RFC 339 (v1) caller->eval BLOCK

> > caller->eval EXPRESSION; > > That's mad, bad, scary and dangerous. Let's do it. Yes, this is cool. In fact, I'm writing Regexp::Func right now as a prototype for RFC 164 and discovering I could really use this - in fact, need it. A couple things: 1. Implement this eval as UNIVERSA

Re: RFC 328 (v2) Single quotes don't interpolate \' and \\

> =head1 ABSTRACT > > Remove all interpolation within single quotes and the C operator, to > make single quotes 100% shell-like. C<\> rather than C<\\> gives a single > backslash; use double quotes or C if you need a single quote in your > string. Yes. If people really need single quotes inside

Why -> cannot autoquote the LHS (was Re: RFC 244 (v1) Method calls should not suffer...)

> =head1 TITLE > > Method calls should not suffer from the action on a distance > Currently, > > foo->bar($baz) > > can be parsed either as C<<'foo'->bar($baz)>>, or as C> > depending on how the symbol C was used on other places. The proposal > is to always choose the first meani

Re: RFC 337 (v1) Common attribute system to allow user-defined, extensible attributes

> > =head1 TITLE > > > > Common attribute system to allow user-defined, extensible attributes > > Err... have you read perldoc attributes? There's already a mechanism > for doing this (see my japh), though it is a complete PITA to use and > I'd like to see it tidied up (and possibly have attribut

Re: RFC 333 (v1) Add C and C funtions to coredistribution

> Hm. This makes it difficult to construct a header incrementally -- for > example, @HEADERS=(); push @HEADERS, header(content_type=>'a', > author=>'b'); # 75 lines later; push @HEADERS, header(last_modified=>'c', > accept=>'d'); > > Since in this case, there would be two "blank" head lines inste

Re: Attribute access

James Mastros wrote: > > As far as setting|getting, I'd like to make a simple proposal. Consider it > an idea for whoever writes the RFC (I'm looking at you, Nate) Oh, jeez, as if I didn't have enough already! ;-) > The idea is this: every variable should have a psudohash of attributes. Idea

Re: RFC 288 (v2) First-Class CGI Support

Alan Gutierrez wrote: > > This header functionality is application specific and does not belong in > the core any more than the socket stuff which seems to be on its way > out. I don't see why this has be implemented in the core in C. > > Once again, if core means core modules, and as a part of

Re: RFC 333 (v1) Add C and C funtions to core distribution

> PS> un is such a lame prefix and very un perl like... unjoin? unpush? > okay so unshift, but still... hey wait I want undelete! Heh. :-) This is not really true, in fact within Perl it is the One True Prefix, ala undef, unlink, unpack, unshift, untie... -Nate

Re: RFC 333 (v1) Add C and C funtions to core distribution

Jonathan Scott Duff wrote: > > My first thought was "this should definitely be in a module" and your > comments just fire those synapses even more strongly. Yes, this will likely end up in a core module. The main thing is that it always has to be available so that pragmas like "use cgi" can impo

Re: Expunge "use English" from Perl? (was Re: Perl6Storm: Intent to RFC #0101)

Simon Cozens wrote: > > On Thu, Sep 28, 2000 at 10:00:49AM -0400, Andy Dougherty wrote: > > On Wed, 27 Sep 2000, Nathan Wiger wrote: > > > Y'know, I couldn't have said this better myself. :-) I've always felt > > > that "use English" was a

Re: RFC 288 (v2) First-Class CGI Support

> A future protocol could well require things in order. Hence you're > having the output headers in order. Therefore you should have the input > ones available in order as well. I don't see a reason why an @HTTP ordered and %HTTP unordered couldn't both be supported. > I'm thinking a $headers_i

Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely

Tom Christiansen wrote: > > >So what's left? > > > >print STDERR "Foo"; > > > >We have a proposal to turn STDERR into $STDERR, and it looks likely it'll go > >through. > > It is? I certainly hope not. It makes as much sense to > do that as to force a dollar sign on subroutines. Your point

Re: Murdering @ISA considered cruel and unusual

Piers Cawley wrote: > > > >I strongly agree with the opinion that we should try and get away from > > >special variables and switches in favor of functions and pragmas. > > >Witness 'use base' instead of '@ISA', 'use warnings', and so on. > > > > Huh? Why??? Perl's use of @ISA is beautiful. It

Re: RFC 288 (v2) First-Class CGI Support

Robert Mathews wrote: > > > Parse the CGI GET/POST request, returning CGI variables into %CGI > > (regardless of the source) in an un-HTTP escaped fashion > > How are you going to handle multiple values for the same parameter? > With CGI.pm, you can say > @values = $q->param("foo"); > > Are y

Re: RFC 288 (v2) First-Class CGI Support

Dan Sugalski wrote: > > >It might be nice if the result of a calculation was never tainted when the > >calculation was in a 'no taint' block. > > Yerk. No, that's bad. The data is still tainted--the fact that it flowed > through a "no taint" block doesn't make it any more trustworthy. Tainting >

Re: Expunge "use English" from Perl?

Adam Turoff wrote: > > It has nothing to do with improving the syntax though, because everything > in use English is a variable that serves as a reference to some other > variable. Yes, and that's why I really think it's a waste of time. ;-) > > I'm not vehemently opposed to "use English"... B

Re: Expunge "use English" from Perl?

> > My personal feeling is that I'd love "use English" to be expunged from > > the language altogether - it's unnecessary bloat that only increases the > > number of mistakes that people can make. But I'm not sure if I have the > > guts to write that RFC just yet. ;-) > > Are you talking about th

Expunge "use English" from Perl? (was Re: Perl6Storm: Intent to RFC #0101)

Russ Allbery wrote: > > I've found the use of use English in code I had to maintain to be annoying > and unhelpful, and to actually degrade the maintainability of the code [snip] > I've yet to understand why I'd *want* to use English regularly; so far as > I can tell, it has essentially no benefit

Re: RFC 288 (v2) First-Class CGI Support

Dan Sugalski wrote: > > >Because taint mode needs to be turned on REEELY early, like before > >pragmas are compiled. > > 'no taint' does make sense, though 'use taint' might not except to locally > undo 'no taint'. Actually, from my talks with Larry both on and off-list about this, he convince

Re: RFC 288 (v2) First-Class CGI Support

Sounds good. I'll start on my 39th :-{ RFC right now... ;-) -Nate Adam Turoff wrote: > > On Wed, Sep 27, 2000 at 11:33:13AM -0700, Nathan Wiger wrote: > > Ziggy, are you interested in this idea enough (at all?) to stick a note > > about the 'header' function

Re: RFC 288 (v2) First-Class CGI Support

Philip Newton wrote: > > > Is order important for @HEADERS? Would it be better to have %HEADERS > > instead that does such auto-formatting? > > In my opinion, no, for the reasons given before. Hashes are unordered, and > if you want to order the keys, you need to know the possibly keys and in >

Re: RFC 259 (v2) Builtins : Make use of hashref context forgarrulousbuiltins

Damian Conway wrote: > >> On the matter of gcos or gecos, and passwd or pw_passwd, and all >> that noise, please consult the User::pwent manpage. >> There's no reason for all those noisy bits. > > Since the standard function provides those noisy bits, this proposal > names them. Not

Re: RFC 19 (v2) Rename the C operator

> Rename the C operator > A list of other proposed replacement names includes (but is not > limited to, since I certainly have forgotten some): > C Unfortunately, I wish this RFC would have taken a stand on at least a first choice. :-( I always thought that "now" was by far the most descriptive

Re: RFC 290 (v2) Better english names for -X

Adam Turoff wrote: > > > PRL> -r freadable() > > PRL> -w fwriteable() > > PRL> -x fexecable() > > PRL> -o fowned() > > > > PRL> -R Freadable() > > PRL> -W Fwriteable() > > PRL> -X Fexecable() > > PRL> -O Fowned() > > > > this looks decent to

Re: RFC 263 (v1) Add null() keyword and fundamental data type

David Grove wrote: > > On Wednesday, September 27, 2000 4:17 AM, Tom Christiansen wrote: > > > This is screaming mad. I will become perl6's greatest detractor and > > anti-campaigner if this nullcrap happens. And I will never shut up > > about it, > > either. Mark my words. > > Quote from Lar

  1   2   3   4   >