Re: RFC 137 (v1) Overview: Perl OO should Inot be fundamentallychanged.

2000-08-22 Thread John Siracusa
On 8/22/00 12:45 AM, Uri Guttman wrote: perl could be the uber OO language, capable of emulating ANY object style. Is this more important than improving performance vs. Perl 5 OO? Not IMO; I want speed. Hey, if I can have both, I'm all for it. But if forced to choose... -John

Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)

2000-08-28 Thread John Siracusa
On 8/28/00 3:09 PM, Damian Conway wrote: (Or, was it already intended that the implementation of 'use invocant' might be some sort of compile-time macro?) No. I think a macro facility for Perl should be more general than just whacking some code in at the start of every subroutine. The

Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)

2000-08-28 Thread John Siracusa
On 8/28/00 3:35 PM, Damian Conway wrote: ...while also giving the compiler enough information to allow such invocant access to execute in an optimized manner...right? C'mon, I'm dying here thinking that all this (admittedly cool) stuff is gonna end up giving Perl 6 even more OO overhead than

Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors

2000-09-01 Thread John Siracusa
On 9/1/00 5:44 PM, Nathan Wiger wrote: sub SETUP { my ($self, @ctor_data) = @_; # initialization of object referred to by $self occurs here } Hmmm. I'm not sure if I like this. I like the *idea* a lot, but I must say that I think I quite like RFC 171's approach better. I haven't

Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors

2000-09-02 Thread John Siracusa
On 9/2/00 11:34 AM, Nathan Wiger wrote: It doesn't seem that it's that hard to add a single line to your SETUP or BLESS or whatever method that calls SUPER::SETUP. I'm pretty sure one of the big points about the system described is that it ensures both that there's always a predictable and

Re: RFC 189 (v1) Objects : Hierarchical calls to initializers anddestructors

2000-09-02 Thread John Siracusa
On 9/2/00 12:12 PM, Nathan Wiger wrote: I think this RFC could work for this, but as I noted in a private email to Damian I'd rather see a whole new keyword made, maybe "setup"? sub new { setup {}, @_ } sub SETUP { ... } Sure, but does setup() bless? That's the question... :) In other

Re: RFC - Interpolation of method calls

2000-09-18 Thread John Siracusa
On 9/18/00 3:44 AM, Damian Conway wrote: my $weather = new Schwern::Example; print "Today's weather will be $weather-{temp} degrees and sunny."; print "And tomorrow we'll be expecting ", $weather-forecast; You are wicked and wrong to have broken inside and peeked at the

Re: RFC 83 (v2) Make constants look like variables

2000-08-16 Thread John Siracusa
On 8/16/00 12:37 PM, Perl6 RFC Librarian wrote: This RFC proposes that the current constant.pm module removed, and replaced with a syntax allowing any variable to be marked as constant. Unfortunately, I submitted an nearly identical RFC yesterday because I didn't see the existing one (I

Re: RFC 83 (v2) Make constants look like variables

2000-08-16 Thread John Siracusa
On 8/16/00 3:55 PM, John Siracusa wrote: On 8/16/00 12:37 PM, Perl6 RFC Librarian wrote: This RFC proposes that the current constant.pm module removed, and replaced with a syntax allowing any variable to be marked as constant. Unfortunately, I submitted an nearly identical RFC yesterday

Re: RFC 113 (v1) Better constants and constant folding

2000-08-16 Thread John Siracusa
On 8/16/00 4:00 PM, Perl6 RFC Librarian wrote: =head1 TITLE Better constants and constant folding =head1 VERSION Maintainer: John Siracusa [EMAIL PROTECTED] Date: Aug 15 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 113 This RFC has been integrated with RFC 83

Re: RFC 126 (v2) Ensuring Perl's object-oriented future

2000-08-28 Thread John Siracusa
On 8/28/00 2:35 PM, Tom Christiansen wrote: Object-oriented features were added to Perl with version 5, and in many ways still appear somewhat "tacked on", with perhaps undue respect for the Old Ways of Perl 4. [NB: This is not a serious missive.] Hey, that Perl uses packages for

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

2000-10-02 Thread John Siracusa
On 10/2/00 1:56 PM, Bart Lateur wrote: The problem with XML is that it is so unforgiving; I think somebody already mentioned that. Improperly nested tags, or one character it doesn't recognize... and the parser says "nyet". Kind of like Perl, huh... ;) (this is a feature, not a bug! :) -John

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

2000-10-02 Thread John Siracusa
On 10/2/00 4:44 PM, John Barnette wrote: * Advanced concepts that POD cannot contain that the XML junkies might want to be used can be embedded. (=for XML) Yeah, but then you get =for HTML, =for XML, =for 3DHOLOGRAM, whatever. No one does that because no one wants to make 50 versions of the

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

2000-10-03 Thread John Siracusa
On 10/3/00 10:59 AM, John Porter wrote: John Siracusa wrote: POD is supposed to be the common format that can be transformed into other representations. Instead, you have to add the different representations yourself if you do anything remotely complex. No, POD is supposed to be simple

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

2000-10-03 Thread John Siracusa
On 10/3/00 12:01 PM, John Porter wrote: John Siracusa wrote: If you add (e.g.) support for tables, then pod is only translatable into languages which also support tables. What languages *don't* support tables? I knew that was a bad example of my point. Think of something complex. O.k

Re: Larry's ALS talk summary

2000-10-30 Thread John Siracusa
Not to seem ungrateful, but is there any hope of getting the slides up as well? You'd think it'd be a no-brainer, but there have been many Wall speeches that have gone by with no slides on the web (well, none that I could find, anyway.) I want to know what the audience is laughing at... :)

Re: Larry's Apocalypse 1

2001-04-06 Thread John Siracusa
On 4/6/01 2:17 PM, Larry Wall wrote: P.S. Larry's Second Law of Language Redesign: Larry gets the colon. My initial reaction: Larry can keep it! ;) (go ahead, make me a believer... :) -John

Re: Tying Overloading

2001-04-23 Thread John Siracusa
On 4/23/01 3:25 PM, Larry Wall wrote: : From a trainer's point of view, having two operators which look very similar, : are used for the same thing in various different languages, and do *almost* : the same thing but not quite, is completely *asking* for confusion. So teach 'em :=, and

Re: Strings vs Numbers (Re: Tying Overloading)

2001-04-23 Thread John Siracusa
On 4/23/01 3:59 PM, Nathan Wiger wrote: Then how do you concatenate a number? Here's something I was thinking about at lunch: $concated_number = $number + $other_number; $numerical_add = $number + $other_number; Why not require in the case when you want to forcible concat a number

Re: s/./~/g

2001-04-23 Thread John Siracusa
On 4/23/01 4:16 PM, Larry Wall wrote: What is it about . that seems to inspire allergic reactions in people? Surely it's not the . itself, but the requirement that you fit everything into that one syntactic mold. Perl's not going to do that. I don't mind it, but I always imagined:

Re: Apoc2 - Context and variables

2001-05-04 Thread John Siracusa
On 5/4/01 11:09 PM, Nathan Wiger wrote: The real trick is what to do with these: Note: stabbing wildly here... :) %a = (%b, %c); %a = (stringify(\%b) = \%c); # Perl 5-ish %a = (%b.str = %c); # Perl 6 equiv. %d = (@e, @f); %d = (stringify(\@e) = \@f); # Perl 5-ish

Re: Apoc2 - Context and variables

2001-05-04 Thread John Siracusa
On 5/4/01 11:47 PM, Edward Peschko wrote: Horrors is right. The default perl5 behaviour is *useful*. I use the %b=(%a,%c) metaphor all of the time. I believe you can get the Perl 5 functionality by throwing a few * characters in there somewhere... Why not just keep it simple? Based on

Re: Apoc2 - Context and variables

2001-05-04 Thread John Siracusa
On 5/5/01 12:06 AM, Nathan Wiger wrote: Maybe we need a way to say flatten these together. I'm going to throw out a new : op here: [snip] Hmmm... I kinda like that... Am I missing anything? Maybe the fact that Larry's already claimed the colon? :) -John

Apoc. 2 and . vs. -

2001-05-04 Thread John Siracusa
As a . doubter form the earlier threads, I'd just like to say that Apoc. 2 has gone a long way towards making me feel better about . as the method call thingie...both by explaining all the neat things . does in Perl 6, and by avoiding the potentially distressing introduction of the replacement

Re: Damian Conway's Exegesis 2

2001-05-15 Thread John Siracusa
On 5/15/01 5:59 PM, Edward Peschko wrote: would be better off written as... ...speaking of which: my int ($pre, $in, $post) is constant = (0..2); What, no caps? my int ($PRE, $IN, $POST) is constant = (0..2); Looks nicer to me...or are all-caps vars reserved for internal use in Perl

Re: Damian Conway's Exegesis 2

2001-05-15 Thread John Siracusa
Okay, this part has me confused. Here we build up a node hash: my %node; %node{LEFT} = undef; %node{RIGHT} = undef; %node{VALUE} = $val is Found(0); $tree = %node; What has the Found property here? I look at that and I think the value associated with %node hash's VALUE

Re: Damian Conway's Exegesis 2

2001-05-15 Thread John Siracusa
On 5/15/01 9:07 PM, Damian Conway wrote: Interestingly, the code would still have *worked* since the (originally unset) property on the node reference would have returned Cundef which would undergo the usual boolean conversion in the Cif, and the usual promotion to zero in the numerical

Re: Generalizing value properties to become postits

2001-07-03 Thread John Siracusa
On 7/3/01 8:14 PM, Damian Conway wrote: You lost me here. Your ideas for properties are different from mine (which may well, in turn, be different from Larry's). Anyone else get the feeling that properties are to Perl 6 what oo was to Perl 5? :) It's like we'll finally be getting the oo bit

Temp properties

2001-08-14 Thread John Siracusa
(I figured it'd take me longer to track this information down myself than it would to get a response from the list. Laziness... :) Can properties be temp()orarily masked? For example: foreach my $array (@arrays) { temp $array.sep = ', '; # assuming this is a real property

Re: Perl 6 - Cheerleaders?

2001-10-28 Thread John Siracusa
On 10/28/01 7:03 PM, Damian Conway wrote: Brent asked: I assume we're going to recycle 'my' and 'our' to be 'instance' and 'class'--is that correct? That's what I'm proposing. So should I start practicing my typos for instance now? Insatance instancae instance. Mmmm... ;P I favour the

Re: Perl 6 - Cheerleaders?

2001-10-28 Thread John Siracusa
On 10/28/01 7:57 PM, Damian Conway wrote: method foo is lvalue { return $foo; Any word on automagical creation of these suckers? No, not as a module, but built-in. I don't think it's too crazy to build *some* sort of sensible attribute accessor

Re: Perl 6 - Cheerleaders?

2001-10-29 Thread John Siracusa
On 10/29/01 1:49 AM, Damian Conway wrote: I guess what I'm really hoping for in Perl 6 is to finally give up my super-simple object base class that does cascading initialization (check) and simple attribute accessor creation (???) when necessary. Yep. I KISS YOU! method foo is lvalue {

Re: Perl 6 - Cheerleaders?

2001-10-29 Thread John Siracusa
On 10/29/01 4:38 PM, Larry Wall wrote: : I'm quite curious to see what the initialization syntax will be like. : : class Demo { : my $foo; : my $bar; : : method INIT ( $fooval, $barval) { : $foo =

Re: Perl 6 - Cheerleaders?

2001-10-29 Thread John Siracusa
On 10/29/01 4:39 PM, Larry Wall wrote: [EMAIL PROTECTED] writes: : On 10/28/01 7:57 PM, Damian Conway wrote: :method foo is lvalue { :return $foo; : : Any word on automagical creation of these suckers? Yes, certainly. Didn't I say that already?

Re: Perl 6 - Cheerleaders?

2001-10-29 Thread John Siracusa
On 10/29/01 8:44 PM, Dan Sugalski wrote: At 12:27 PM 10/30/2001 +1100, Damian Conway wrote: nuch SoH! bIQambogh DaqDaq qaHoH! The biggest problem with reading mail from Damian is I keep wanting to rot13 the thing.. Whatever filter he's running his thoughts through, I'm pretty sure it's

Re: Auto-creation of simple accessors (was: Perl 6 -Cheerleaders?)

2001-10-30 Thread John Siracusa
Okay, so we've got these guys auto-created if we want: method foo is lvalue { return $.foo } (plus or minus the syntax) which lets us do: $obj.foo = 5; print $obj.foo; So, what about simple array accessors? $obj.colors('red', 'green', 'blue'); $obj.colors = ('red',

Re: Auto-creation of simple accessors (was: Perl 6 -Cheerleaders?)

2001-10-30 Thread John Siracusa
On 10/30/01 12:13 PM, Brent Dax wrote: John Siracusa: Please note that these are my best guesses; I'm not a Damian ;^). # $obj.colors('red', 'green', 'blue'); # # $obj.colors = ('red', 'green', 'blue'); # # $obj.colors = ['red', 'green', 'blue' ]; $obj.colors=('red

Quick EX3 question

2001-10-06 Thread John Siracusa
Are these the same thing? print _@{$data.{costs}}; print _ $data{costs}; -John

EX3: $a == $b != NaN

2001-10-06 Thread John Siracusa
Okay, so this: 100 -s $filepath = 1e6 really means this: 100 -s $filepath-s $filepath = 1e6 which means that this: $a == $b != NaN really means this: $a == $b $b != NaN But $a == $b != NaN is supposed to [solve] the problem of numerical comparisons between

EX3: Adverbs and print()

2001-10-06 Thread John Siracusa
From EX3: A subroutine's adverbs are specified as part of its normal parameter list, but separated from its regular parameters by a colon: my sub operator:… is prec(\operator:+($)) ( *@list : $filter //= undef) { ... This specifies that operator:… can take a single scalar adverb, which is

Re: EX3: $a == $b != NaN

2001-10-06 Thread John Siracusa
On 10/6/01 10:27 PM, Damian Conway wrote: Doesn't that mean: hello == 0 0 != NaN will evaluate to true? No. The step you're missing is that the non-numeric string hello, when evaluated in a numeric context, produces NaN. So: hello == 0 0 != NaN is: Nan ==

Re: EX3: Adverbs and print()

2001-10-10 Thread John Siracusa
On 10/10/01 7:27 AM, Piers Cawley wrote: Bart Lateur [EMAIL PROTECTED] writes: On Sat, 06 Oct 2001 22:20:49 -0400, John Siracusa wrote: So, in the … operator, the filter is the adverb: $sum = … @costs : {$^_ 1000}; WTF is that operator? All I see is a black block. We're

Re: Barewords and subscripts

2002-01-27 Thread John Siracusa
On 1/27/02 9:57 AM, Simon Cozens wrote: I can't help thinking that requiring quotes will make it all nice and consistent, and completely zap all these edge cases. Well, it'll sure make the subset of Perl programmers who have always quoted hash subscripts anyway (like me--usually with single

Re: Perl6 -- what is in a name?

2002-01-28 Thread John Siracusa
On 1/28/02 9:43 PM, Bryan C. Warnock wrote: So, what *is* in a name? If a rose by any other name would smell just as sweet, why continue to call it a rose? Because identifiers are a proxy for what they represent - an evocation of the object without benefit of having one. Heh, programmer

Re: Exegesis 4

2002-04-03 Thread John Siracusa
On 4/3/02 3:44 AM, Damian Conway wrote: Larry indicated to me that blockless declarations of methods and subs would be illegal. What's the motivation for this? It seems to me that pre-declarations would be just as nice (or nicer) as: module Alpha; package Beta; method

Re: Exegesis 4

2002-04-03 Thread John Siracusa
On 4/3/02 12:07 PM, Brent Dax wrote: John Siracusa: # On 4/3/02 3:44 AM, Damian Conway wrote: # Larry indicated to me that blockless declarations of # methods and subs would be illegal. # # What's the motivation for this? I assume it's to support the Perl 5 blockless style. Ah, yeah

$^a, $^b, and friends

2002-04-03 Thread John Siracusa
Reading EX4 and seeing those place-holder variables made me wonder what happens when someone (probably Damian ;) wants to use more than 26 of them. Do the place-holder names scale up as if they're being automagically incremented? (e.g. ..., y, z, aa, ab, ...) -John

Re: $^a, $^b, and friends

2002-04-03 Thread John Siracusa
On 4/3/02 12:49 PM, Jonathan Scott Duff wrote: On Wed, Apr 03, 2002 at 12:41:13PM -0500, John Siracusa wrote: Reading EX4 and seeing those place-holder variables made me wonder what happens when someone (probably Damian ;) wants to use more than 26 of them. Do the place-holder names scale up

Re: Exegesis 4

2002-04-03 Thread John Siracusa
On 4/3/02 6:44 PM, Damian Conway wrote: Larry has said very clearly that in Perl 6 there are no magical lexical scopes. Shouldn't this be: Larry has said very clearly that in Perl 6 there is only one 'magical' lexical scope: sub() or - -John

Re: Unary dot

2002-04-15 Thread John Siracusa
On 4/15/02 1:16 AM, Damian Conway wrote: More interestingly, it may also be that, by default, the Coperator:{} (i.e. hash-look-up) method of a class invokes the accessor of the same name as the key, so that: $foo.bar_attr = 1; could also be written: $foo.{bar_attr} = 1; and still

Re: Unary dot

2002-04-15 Thread John Siracusa
On 4/15/02 5:16 PM, Damian Conway wrote: if we don't support this, people will be forever having to create Perl 6 adapter classes just so that they can make use of legacy Perl 5 code. :-( Okay, how about making it a pragma that's not enabled by default? So all those Perl 5 porters can do

Re: Unary dot

2002-04-15 Thread John Siracusa
On 4/15/02 10:24 PM, Larry Wall wrote: So the main reason that objects can function as hashes is so that the user can poke an object into an interface expecting a hash and have it make sense, to the extent that the object is willing to be viewed like that. Sure, by why should that be the

Re: 6PAN (was: Half measures all round)

2002-06-04 Thread John Siracusa
On 6/4/02 12:22 PM, David Wheeler wrote: I think that if we can agree to forego backwards compatibility, we might also be in a better position to set up a CP6AN with much better quality control. All of the most important modules will be ported very quickly (e.g., the DBI), and a lot of the

Re: Re: 6PAN (was: Half measures all round)

2002-06-04 Thread John Siracusa
On 6/4/02 12:34 PM, Steve Simmons wrote: As for CPAN . . . don't get me started. CPAN is a blessing, but has become a curse as well. It's contents need to be razed to the ground and better/more conistant rules set up for how to do installations into and out of the standard trees. If you

Re: 6PAN (was: Half measures all round)

2002-06-04 Thread John Siracusa
On 6/4/02 1:11 PM, David Wheeler wrote: On 6/4/02 9:59 AM, John Siracusa [EMAIL PROTECTED] claimed: 1b. 6PAN modules comply with an informal contract to maintain backward-compatibility within all N.MM versions, where N is constant. In other words, incompatible API changes are only allowed

Re: 6PAN (was: Half measures all round)

2002-06-04 Thread John Siracusa
On 6/4/02 1:26 PM, Larry Wall wrote: : Speaking of CPAN for Perl 6 (or CP6AN, or 6PAN), what's the status of : this effort? Do we even have a vague idea of the requirements? Or does : everyone think CPAN (and module distribution/installation in general) as it : exists now it pretty much

Re: 6PAN (was: Half measures all round)

2002-06-04 Thread John Siracusa
On 6/4/02 3:59 PM, Steve Simmons wrote: : 1c. Distinctions like alpha, beta, and stable need to be made : according to some convention (a la $VERSION...perhaps $STATUS?) Can probably burn that bridge when we get to it. Frankly, I'd argue that nothing in 6PAN ought to be in alpha/beta

Re: 6PAN (was: Half measures all round)

2002-06-05 Thread John Siracusa
On 6/5/02 2:59 PM, Steve Simmons wrote: Sticking just to the disk-intensive issue for a moment -- [...] With the new one, we seem to have agreed that `most recent' will be used, not `first found'. That means that every tree must be probed, and probed with globs or sub-searches to match the

Re: A5: a few simple questions

2002-06-06 Thread John Siracusa
On 6/6/02 2:43 AM, Damian Conway wrote: rule wordlist { (\w+) [ , (\w+) ]* } No semicolon at the end of that line? I've already forgotten the new rules for that type of thing... :) -John

Re: Apoc 5 questions/comments

2002-06-07 Thread John Siracusa
On 6/7/02 4:48 PM, Luke Palmer wrote: rule tag($name) {:w \ $name %opts:=[ (\S+)=(\S+) ]* \ } Then, you can match an img tag with: / tag 'img' / See, isn't that great? Don't you mean, see, isn't that massively over-simplified? ;) (but yeah, we get the idea... :) -John

Re: Apoc 5 questions/comments

2002-06-07 Thread John Siracusa
On 6/7/02 4:51 PM, Damian Conway wrote: I have no doubt that, once Perl 6 is available, we'll see a rash of modules released in the Grammar:: namespace. Including Grammar::HTML and Grammar::XML. Why not just make Grammar::DTD, and then make Grammar::Generator::FromDTD. Then use those to make

Re: Apoc 5 questions/comments

2002-06-07 Thread John Siracusa
On 6/7/02 5:44 PM, Damian Conway wrote: John Siracusa wrote: I have no doubt that, once Perl 6 is available, we'll see a rash of modules released in the Grammar:: namespace. Including Grammar::HTML and Grammar::XML. Why not just make Grammar::DTD, and then make Grammar::Generator::FromDTD

More 6PAN musings: local namespaces

2002-06-15 Thread John Siracusa
Once nice thing about Java is the class naming convention that lets individual companies (or even individuals, I guess) do custom development that they can safely integrate with the standard Java classes and the work of other companies/individuals without fear of namespace clashes. For example,

Re: More 6PAN musings: local namespaces

2002-06-16 Thread John Siracusa
On 6/16/02 1:50 AM, Luke Palmer wrote: On Sun, 16 Jun 2002, Michael G Schwern wrote: Let's dump out the sack of namespace partitioning problems: What if Acme decides it wants to release part of it's code as Open Source? (Happens a lot). Does it release it as Com::Acme::Text::Thing or

Re: More 6PAN musings: local namespaces

2002-06-18 Thread John Siracusa
On 6/18/02 6:10 PM, Damian Conway wrote: Larry has previously mentioned the prospect of Perl 6 module names being extended to include version number and author. If this were to be done, would seem reasonable for the author component to simply be the author's CPAN username. These are

Re: More 6PAN musings: local namespaces

2002-06-18 Thread John Siracusa
On 6/18/02 8:32 PM, Larry Wall wrote: I expect to end up with a multi-level system, where you can use anything from a DNS name (guaranteed to contain dots) through author IDs (no dots) to blessed top-level names for universally acclaimed modules, for some definition of universal. I'm not

Re: Perl6 Operator List

2002-10-26 Thread John Siracusa
On 10/26/02 7:24 PM, Simon Cozens wrote: To the innocent bystanders, I hope you're not buying any of this crap about Perl 6 being more regular or removing the inconsistencies of Perl 5. It simply isn't true. I was buying that right up until about a week or two ago when Larry emerged from his

Re: Perl6 Operator List

2002-10-26 Thread John Siracusa
On 10/26/02 8:18 PM, Larry Wall wrote: On 27 Oct 2002, Simon Cozens wrote: : To the innocent bystanders, I'm afraid you're preaching to the null set here. :-) I don't know whether to be flattered that you think I'm not just a bystander, or insulted that you think I'm not innocent ;) -John

Re: plaintive whine about 'for' syntax

2002-10-31 Thread John Siracusa
On 10/31/02 5:33 PM, [EMAIL PROTECTED] wrote: Damian Conway writes: BTW, Both Larry and I do understand the appeal of interleaving sources and iterators. We did consider it at some length back in January, when we spent a week thrashing this syntax out. Of course, I can't speak for Larry,

Re: Stringification of references and objects.

2002-12-06 Thread John Siracusa
On 12/6/02 4:41 PM, Michael Lazzaro wrote: my PersonName $name = .new(...); my FormalStr $s = $name;# Dr. William P. Smith my InformalStr $s = $name;# Bill Whether that is good, bad, or indifferent I leave to the OO Police. I'm not even deputized, but I call foul: excessive use

Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))

2002-12-11 Thread John Siracusa
On 12/11/02 6:16 PM, Damian Conway wrote: There's no need for special methods or (gods forbid) more operators. Just: $obj1.id == $obj2.id That's what the universal Cid method is *for*. I must have missed this (or forgotten it?) Any chance of it becoming .ID or .oid or even ._id? I'm

Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))

2002-12-12 Thread John Siracusa
On 12/12/02 12:55 PM, Larry Wall wrote: As for namespace pollution and classes that use .id in Perl 5, I don't think it's going to be a big problem. Built-in identifiers do not have a required prefix, but they have an optional prefix, which is C*. I think we can probably parse $a.*id ==

Re: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]

2002-12-12 Thread John Siracusa
On 12/12/02 4:01 PM, Larry Wall wrote: On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote: : So we'll _have_ to write $obj.*id when we mean $obj-UNIVERSAL::id; If you wish to be precise, yes. But $a.id eq $b.id should work for most any class that uses the the term id in the

Re: Comparing Object Identity

2002-12-12 Thread John Siracusa
On 12/12/02 4:41 PM, Dave Whipp wrote: John Siracusa [EMAIL PROTECTED] wrote: memory addresses is so infrequent that warrants a much less common and/or longer method name than id. Another reason for not making these synonymous: [...] If memory addresses can change over time, then we

Re: Comparing Object Identity [x-adr][x-bayes]

2002-12-13 Thread John Siracusa
On 12/13/02 10:49 AM, Garrett Goebel wrote: John Siracusa wrote: Using the method/attribute named id for this is the same object comparisons is just plain bad Huffman coding. The this is the same object method/attribute should have a name that reflects the relative rarity of its use

Re: Comparing Object Identity

2002-12-13 Thread John Siracusa
On 12/13/02 12:44 PM, Michael Lazzaro wrote: On Thursday, December 12, 2002, at 06:55 PM, James Mastros wrote: And I'd say (but who asked me -- IMHO, of course) that it should be perfectly valid to write code like the above. (That IDs should be unique across a process over all time.) If

Disappearing code

2003-01-09 Thread John Siracusa
Has there been any discussion of how to create code in Perl 6 that's there under some conditions, but not there under others? I'm thinking of the spiritual equivalent of #ifdef, only Perlish. In Perl 5, there were many attempts to use such a feature for debugging and assertions. What everyone

Re: Disappearing code

2003-01-09 Thread John Siracusa
On 1/9/03 9:01 PM, Luke Palmer wrote: Well, I just do: sub debug { print STDERR shift, \n if DEBUG; } And hopefully (I don't know P5 internals so well) that optimizes to a no-op so there's not even a function call there. I don't know P5 internals so well either, but I'm guessing

Re: Disappearing code

2003-01-09 Thread John Siracusa
On 1/9/03 10:10 PM, Michael G Schwern wrote: I would assume it to be a compiler hint via subroutine attribute. sub debug ($msg) is off { print STDERR $msg; } some this subroutine is a no-op if a flag is set attribute. Hm, not quite as convenient as setting a package global

Re: Disappearing code

2003-01-10 Thread John Siracusa
On 1/9/03 11:27 PM, Michael G Schwern wrote: On Thu, Jan 09, 2003 at 11:15:49PM -0500, John Siracusa wrote: On 1/9/03 10:10 PM, Michael G Schwern wrote: I would assume it to be a compiler hint via subroutine attribute. sub debug ($msg) is off { print STDERR $msg; } some

Re: Disappearing code

2003-01-10 Thread John Siracusa
On 1/10/03 11:11 AM, Dan Brook wrote: On Thu, 09 Jan 2003 19:55:20 -0500 John Siracusa [EMAIL PROTECTED] wrote: Has there been any discussion of how to create code in Perl 6 that's there under some conditions, but not there under others? I'm thinking of the spiritual equivalent of #ifdef

Wrappers vs. efficiency - quick comment

2003-03-11 Thread John Siracusa
From A6: I worry that generalized wrappers will make it impossible to compile fast subroutine calls, if we always have to allow for run-time insertion of handlers. Of course, that's no slower than Perl 5, but we'd like to do better than Perl 5. Perhaps we can have the default be to have

Re: Wrappers vs. efficiency - quick comment

2003-03-12 Thread John Siracusa
On 3/12/03 1:50 AM, Mark Biggar wrote: John Siracusa wrote: From A6: I worry that generalized wrappers will make it impossible to compile fast subroutine calls, if we always have to allow for run-time insertion of handlers. Of course, that's no slower than Perl 5, but we'd like to do better

Perl 6's for() signature

2003-07-31 Thread John Siracusa
From an old summary: http://www.perl.com/pub/a/2003/04/p6pdigest/20030427.html?page=2 Paul Hodges took a crack at implementing for as a subroutine and came up with something that didn't look too insane. Luke Palmer added a refinement allowing for n at a time looping. However, for reasons

Re: Perl 6's for() signature

2003-07-31 Thread John Siracusa
On Thursday, July 31, 2003, at 12:05 PM, Luke Palmer wrote: Well, I don't think it's possible, actually. There's a flattening list context at the beginning (implying a sugary drink from 7 eleven), followed by a code block. But, as we know, slurpy arrays can only come at the end of positional

Re: This week's summary

2004-01-05 Thread John Siracusa
On 1/5/04 1:55 PM, Lars Balker Rasmussen wrote: The Perl 6 Summarizer [EMAIL PROTECTED] writes: I confess I wouldn't be surprised if, by the end of the year, we haven't seen the full implementation of at least one of the big non-Perl scripting languages on top of Parrot. I'm confused, are

Re: Mutating methods

2004-03-11 Thread John Siracusa
On 3/11/04 4:04 PM, Larry Wall wrote: On Thu, Mar 11, 2004 at 12:43:22PM -0800, Larry Wall wrote: : Which is precisely the problem with something like : : $a cmp= $b : : insofar as $a is being treated as a string at one moment and as a boolean : at the next. Well, okay, not a

Re: Mutating methods

2004-03-12 Thread John Siracusa
On 3/12/04 12:43 PM, Larry Wall wrote: Some good questions only have bad answers. This might be one of them. I have been watching this thread with increasing unease, asking myself exactly what the potential benefit is of this proposed feature and syntax. I'm all for saving some typing, but

Re: Apocalypse 12

2004-04-17 Thread John Siracusa
On 4/17/04 6:22 AM, Piers Cawley wrote: chromatic [EMAIL PROTECTED] writes: Warning -- 20 pages, the first of which is a table of contents. But it's all excellent good stuff. Well done Larry and Co. Now, if you could all just hold off with the questions 'til Monday you'll make a summary

A12: Required Named Parameters Strike Back!

2004-04-19 Thread John Siracusa
Those with encyclopedic knowledge of the perl6-language list will recall my impassioned, but ultimately futile plea for required named parameters--that is, required arguments to a function that must be supplied as pairs rather than positionally. Here's a post from the middle of that old thread:

Re: Apo 12

2004-04-19 Thread John Siracusa
On 4/19/04 11:11 AM, Larry Wall wrote: On Sat, Apr 17, 2004 at 01:12:58PM -0400, Austin Hastings wrote: : If it's not totally obvious to everyone, you should download a copy of A12 : (I like the printer-friendly all-in-one-page version) as a hedge against : the almost-inevitable slashdotting.

Re: A12: Required Named Parameters Strike Back!

2004-04-19 Thread John Siracusa
On 4/19/04 1:30 PM, Larry Wall wrote: On Mon, Apr 19, 2004 at 01:14:57PM -0400, John Siracusa wrote: : I know we are running out of special characters, but I really, really think : that required named parameters are a natural fit for many common APIs. A12 : has reinforced that belief. Save

Re: A12: Required Named Parameters Strike Back!

2004-04-19 Thread John Siracusa
On 4/19/04 1:41 PM, Dan Sugalski wrote: At 1:14 PM -0400 4/19/04, John Siracusa wrote: I know we are running out of special characters, but I really, really think that required named parameters are a natural fit for many common APIs. Well... maybe, but ponder a likely common case

A12: Naming Police - P6opaque

2004-04-19 Thread John Siracusa
From page 7: In any event, strings are reserved for other object layouts. We could conceivably have things like: return $class.bless(Cstruct, *%_); So as it happens, 0 is short for the layout P6opaque. I feel like we have pretty well staked out the letters p-e-r-l, but anything else is

A12: default accessors and encapsulation

2004-04-19 Thread John Siracusa
Let's say I have a class with some attributes: class Dog; has $.name is rw; has $.age is rw; has $.gender is rw; I initially decide to accept the default accessors. $dog.name = 'Ralph'; print $dog.age; This works well for a while, but then I decide to update Dog so

Re: A12: Naming Police - P6opaque

2004-04-19 Thread John Siracusa
On 4/19/04 3:36 PM, Larry Wall wrote: On Mon, Apr 19, 2004 at 02:04:55PM -0400, John Siracusa wrote: : So, how about Perl6opaque (or Perl6Opaque), just to be safe :) How 'bout just Opaque, meaning Parrot's native object type, or whatever the native opaque type is for the platform in question

Re: A12: default accessors and encapsulation

2004-04-19 Thread John Siracusa
On 4/19/04 3:58 PM, Austin Hastings wrote: I initially decide to accept the default accessors. $dog.name = 'Ralph'; print $dog.age; This works well for a while, but then I decide to update Dog so that setting the name also sets the gender. $dog.name = 'Susie'; # also sets

Re: A12: default accessors and encapsulation

2004-04-19 Thread John Siracusa
On 4/19/04 4:47 PM, [EMAIL PROTECTED] wrote: On 4/19/04 3:58 PM, Austin Hastings wrote: One work-around might be an alternate kind of default accessor that doesn't allow assignment: $dog.name # get $dog.name('foo') # set $dog.name = 'foo' # compile-time error I

Re: A12: Required Named Parameters Strike Back!

2004-04-20 Thread John Siracusa
On 4/19/04 7:16 PM, Larry Wall wrote: On Mon, Apr 19, 2004 at 01:44:53PM -0400, John Siracusa wrote: : ...named and required, or named and optional? IOW, is this all true? : : sub foo(+$a, +$b) { ... } : : foo(); # compile-time error! : foo(1, 2); # compile-time

Re: A12: default accessors and encapsulation

2004-04-20 Thread John Siracusa
On 4/19/04 7:20 PM, Larry Wall wrote: On Mon, Apr 19, 2004 at 06:53:29PM -0400, John Siracusa wrote: : Yeah, that's exactly what I don't want to type over and over :) I really don't understand what you're getting at here. First you complain that you'd rather write an ordinary method

  1   2   >