Re: can a method name contain a funny character?

Thanks for the in-depth analysis. My misunderstanding was about what an identifier considers a number; I have no well-thought-out ideas on the subject of what an identifier ought to be. Having the docs mention that "number" means only characters with a Unicode Property GeneralCategory of Nd might

Re: can a method name contain a funny character?

On Fri, May 20, 2016 at 09:39:30AM -0400, yary wrote: : On Tue, Apr 12, 2016 at 6:12 PM, Brandon Allbery : wrote: : > I was explaining why some "symbols" are acceptable to the parser. Which : one : > is more appropriate is not my call, : : I was thinking about what exactly are valid identifiers i

Re: can a method name contain a funny character?

To be clear, I expect that "number" in "followed by zero or more word characters (alphabetic, underscore or number)" means "if Unicode thinks it's numeric, you can use it in an identifier after the first character." I don't expect that every numeric codepoint in Unicode must evaluate to number in

Re: can a method name contain a funny character?

On Tue, Apr 12, 2016 at 6:12 PM, Brandon Allbery wrote: > I was explaining why some "symbols" are acceptable to the parser. Which one > is more appropriate is not my call, I was thinking about what exactly are valid identifiers in Perl6/rakudo's implementation. The docs

[perl6/specs] 33eaff: Update Supply introduction and method docs for ser...

-concurrency.pod Log Message: --- Update Supply introduction and method docs for serial supplies Also some Channel clarifications. Commit: cc534c403199b0804fe05bd5cb88676142a878a1 https://github.com/perl6/specs/commit/cc534c403199b0804fe05bd5cb88676142a878a1 Author: skids

[perl6/specs] 627f2a: Fix -> vs . method call typo in S17

-concurrency.pod Log Message: --- Fix -> vs . method call typo in S17

[perl6/specs] e15acb: Re-purpose the method ^foo(...) { ... } syntax.

: M S12-objects.pod Log Message: --- Re-purpose the method ^foo(...) { ... } syntax. The existing design of it was out of line with the way Perl 6 evolved since then, and also not especially useful. This takes the syntax and enables its use for per-type meta-behavior specialization

[perl6/specs] 8c901d: Refer to .content method for Pod blocks rather tha...

-documentation.pod Log Message: --- Refer to .content method for Pod blocks rather than .contents

[perl6/specs] f143d1: Supply.(zip|merge) can be called as class method

: M S17-concurrency.pod Log Message: --- Supply.(zip|merge) can be called as class method

[perl6/specs] 379579: [S05] Reintroduce the .ast method.

Log Message: --- [S05] Reintroduce the .ast method. Every good language has a few synonyms anyway :) .

[perl6/specs] 24373d: Rename .ast method to .made

: M S02-bits.pod M S05-regex.pod Log Message: --- Rename .ast method to .made This makes much more sense when paired with "make". It also makes the generic examples of make that jnthn++ used in his http://jnthn.net/papers/2014-fosdem-perl6-today.pdf (slide #24 and

[perl6/specs] ae7cf3: Define .narrow method to narrow numeric types

-setting-library/Numeric.pod Log Message: --- Define .narrow method to narrow numeric types Can narrow either Rat or Num to Int, for instance. Resolves #47.

[perl6/specs] 29e1f7: Change use of .elems on Set/Bag/Mix to new method ...

: M S32-setting-library/Containers.pod Log Message: --- Change use of .elems on Set/Bag/Mix to new method .total

[perl6/specs] 41296c: [S12]: bless is a method, not a function

-objects.pod Log Message: --- [S12]: bless is a method, not a function

[perl6/specs] 0cca60: round method produces a Real, not always Int

-setting-library/Numeric.pod Log Message: --- round method produces a Real, not always Int provided a better description of what the specced algorithm actually does

[perl6/specs] b49be3: Remove mention of .exists method from example, rep...

: M S11-modules.pod Log Message: --- Remove mention of .exists method from example, replace by :exists adverb

[perl6/specs] 01c9f4: Added some identical method based examples, seemed...

: M S32-setting-library/Containers.pod Log Message: --- Added some identical method based examples, seemed appropriate

[perl6/specs] 5faf89: [S02] Small clarification about method .tree

Log Message: --- [S02] Small clarification about method .tree Make it clear that the phrase "level-sensitive map" refers to the specific C function/method, as opposed to some general concept of a map.

[perl6/specs] 18c244: Replace mention of now defunct .file method by de-...

: M S03-operators.pod Log Message: --- Replace mention of now defunct .file method by de-facto .path

[perl6/specs] a3b902: don't really need a .powerset method

-setting-library/Containers.pod Log Message: --- don't really need a .powerset method also, allow a too-bit range to stop at size of the container

[perl6/specs] b1c338: add combinations method

-setting-library/Containers.pod Log Message: --- add combinations method

Re: The .trans method and Least Surprise

yary (>): > Speaking as a non-p6-coder "proposal sounds good to me" though the > spec raises some other questions. > >>The tr/// quote-like operator now also has a method form called >> trans(). Its argument is a list of pairs. You can use any

Re: The .trans method and Least Surprise

Speaking as a non-p6-coder "proposal sounds good to me" though the spec raises some other questions. >The tr/// quote-like operator now also has a method form called > trans(). Its argument is a list of pairs. You can use anything > that produces a pair list: > > $

The .trans method and Least Surprise

Something's bothering me about the .trans method. This email lists a proposal to split its semantics into two methods. I'm not yet convinced myself about this proposal. It's quite late in the game to make spec changes of established methods, and the change will break some downstr

[perl6/specs] 578e3c: [S04] un-spec method-level PRE/POST

-control.pod Log Message: --- [S04] un-spec method-level PRE/POST The intent was to extend block-level PRE/POST to something that could do Eiffel-style Design-by-Contract assertions. This is an intriguing idea, but not in the way the spec outlined it. See <http://www.nntp.perl.org/gr

[perl6/specs] 8a9969: [S06] avoid indirect method call syntax

-routines.pod Log Message: --- [S06] avoid indirect method call syntax It is unrelated to the topic, and seem to confuse readers. Me too.

[perl6/specs] e1c674: Add conjugate method (for RT 76602)

/Numeric.pod Log Message: --- Add conjugate method (for RT 76602)

Method 'Bool' not found for invocant of class 'Integer'

I've tried copying everything over and I can't seem to find what is present in the rakudo directory but not in the one for my executable. Is there some c method I can call to point a parrot interpreter at a particular runtime directory -- like the same one as rakudo/perl6 itself uses?

[perl6/specs] 61e2e1: copy-paste issues with new roll method

/Containers.pod Log Message: --- copy-paste issues with new roll method jkpeters_37++ points out a problem in the new specs for .roll, which are now revised for (I hope) more clarity.

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

jnthn++ points out in meatspace that the invocant parameter has a constraint (by spec but not in Rakudo), which will carry over to the new class. Which means that only objects of child classes will signature-bind anyway. // Carl

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

On 2010-07-31 20:23, Carl Mäsak wrote: * Today we discovered that it's possible to break encapsulation by detaching a method from an object of one class, and calling that method on an object of another class. Which means that breaking the encapsulation of a foreign class is as easy as creat

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

Carl (>>), Moritz (>): >> * If it isn't allowed, which of the two steps is disallowed? >> *Detaching* a method containing references to private accessor slots >> (thereby extending the syntactic restriction of "no private accessors >> outside of the

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

ng introspection techniques (which aren't fully specced yet, but they *will* exist. In case of doubt you can just parse .perl output). > * If it isn't allowed, which of the two steps is disallowed? > *Detaching* a method containing references to private accessor slots > (thereby ext

rounding method adverbs

ation for any numeric operations that might do rounding, where users specify the rounding method employed. For example, the Int-resulting division and modulo operators should require specifying how to round on an uneven division. I can think of at least 9 rounding methods to choose from off

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

Carl (>>), sorear (>): >> * It has been decided that attribute slots of the type $!foo are only >> allowed *syntactically* within the class block that declares them. >> (The exception to this, I guess, is the 'trusts' directive.) But this >> mean

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/31/10 14:38 , Stefan O'Rear wrote: > On Sat, Jul 31, 2010 at 02:36:02PM -0400, Brandon S Allbery KF8NH wrote: >> The whole concept of detaching and attaching methods seems suspect to me; in >> particular, attaching a met

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

> > I must confess I don't particularly like either option. I'm by no > > means an OO expert. It would be interesting to hear your views on > > this. > > The whole concept of detaching and attaching methods seems suspect to me; in > particular, attaching a

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

; means that something like this anonymous method > > my $reveal-foo = method { say $!foo } > > isn't allowed. I think that's good, because it would provide a very > easy way to break encapsulation of an object; just call > $object.$reveal-foo() on it. There is no

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

ither option. I'm by no > means an OO expert. It would be interesting to hear your views on > this. The whole concept of detaching and attaching methods seems suspect to me; in particular, attaching a method from a class not declared to be related reeks of monkey patching. As such

Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

has been decided that attribute slots of the type $!foo are only allowed *syntactically* within the class block that declares them. (The exception to this, I guess, is the 'trusts' directive.) But this means that something like this anonymous method my $reveal-foo = method { say

Mixing in to method objects

As I understand it, in Perl 6 a method of a class, as indeed all similar things like a sub or a regex, is represented by an object. If it's an object, I should be able to mix a role into it, right? Something like: role Fancy { has $.something is rw; } sub a { } &a does Fancy; &am

Re: [perl #62528] Match.keys method returns nothing.

Moritz Lenz wrote: > Since afaict this is not specced, I'll hand that over to p6l. > > Eric Hodges (via RT) wrote: >> use v6; >> >> rule test {test}; >> >> "test" ~~ //; >> say '$/.keys => ', $/.keys.perl; >> say '%($/).keys => ', %($/).keys.perl; >> >> # outputs >> # $/.keys => [] >> # %($/).keys

Re: [perl #62528] Match.keys method returns nothing.

Since afaict this is not specced, I'll hand that over to p6l. Eric Hodges (via RT) wrote: > use v6; > > rule test {test}; > > "test" ~~ //; > say '$/.keys => ', $/.keys.perl; > say '%($/).keys => ', %($/).keys.perl; > > # outputs > # $/.keys => [] > # %($/).keys => ["test"] > > > Same could be

[perl #60258] Matching against a method produces the wrong result in Rakudo

On Fri Oct 31 06:31:53 2008, masak wrote: > Rakudo r32247 does the wrong thing when matching a something against > the ".method" syntax. > > $ perl6 -e 'class A { method alwaystrue { return 1 } }; given A.new { > say "irrelevant" ~~ .alwaystrue }' &g

Method Postfix sleuthing...

What does <.:> mean? Now, meth is really , which can be one of three things: a method name (or variable with such in it) a postfix operator which in this context is just <++>, <-->, and their hyper forms ?? I think I heard that in this cont

Re: [PATCH] Add .trim method

On 2009 Jan 12, at 15:17, Ovid wrote: " בָּרוּךְ שֵׁם כְּבוֹד מַלְכוּתוֹ לְעוֹלָם וָעֶד." If you can't see that in your client, that's Hebrew from http://www.i18nguy.com/unicode/shma.html and means "Hear O Israel, the Lord is our God, the Lord is One". Actually that's the res

Re: [PATCH] Add .trim method

On Mon, Jan 12, 2009 at 6:26 PM, Ovid wrote: > - Original Message > > > From: jason switzer > > > If we wanted language dependent version, use :leading, :trailing, and > :both. > > That will require each implementation properly handle the language > > variations. > > I think :start and :

Re: [PATCH] Add .trim method

- Original Message > From: jason switzer > If we wanted language dependent version, use :leading, :trailing, and :both. > That will require each implementation properly handle the language > variations. I think :start and :end are my favorites. Huffman++ (maybe :begin and :end for c

Trimming; left or start? (was: Re: [PATCH] Add .trim method)

Can I make a suggestion? From my point of view, it'd be nice if the trim method supported: - left/right (leftmost/rightmost part of the string; language-independent) - start/end (start and end of string; could be leading/trailing instead) - both How would that

Re: [PATCH] Add .trim method

On Mon, Jan 12, 2009 at 9:07 AM, jesse wrote: > > 'left' and 'right' are probably not the right names for functions which > trim leading and/or trailing space, since their meanings get somewhat > ambiguous if a language renders right-to-left instead of left-to-right > or vice-versa > I'm in favo

Re: [PATCH] Add .trim method

On Mon, Jan 12, 2009 at 4:19 PM, Aristotle Pagaltzis wrote: > Maybe :h and :t (head/tail). I like the echo of the csh pathname modifiers there. Unless that confuses people into thinking that .trim has something to do with pathname canonicalization... -- Mark J. Reed

Re: [PATCH] Add .trim method

to take that lead... : > : > How about .trim(:start) and .trim(:end)? : : That would be my favourite: : : our Str multi method trim (Str $string:, :start = True, :end = True) Er, that would make .trim(:start) also default :end to True... Well, except it won't parse either. For at least two

Re: [PATCH] Add .trim method

tions welcome as I can't think of anything better. >> >> The .Net framework calls 'em TrimStart and TrimEnd (and has a Trim that does >> both). So maybe trim_start and trim_end if we wanted to take that lead... > > How about .trim(:start) and .trim(:end)? That would be

Re: [PATCH] Add .trim method

On Jan 12, 2009, at 11:27 AM, Carl Mäsak wrote: How about .trim(:start) and .trim(:end)? And .trim(:both) for orthogonality. -- Andy Lester => a...@petdance.com => www.petdance.com => AIM:petdance

Re: [PATCH] Add .trim method

On Mon, Jan 12, 2009 at 07:01:25AM -0800, Ovid wrote: > > > > I could optionally make the following work: > > > > > > > > $string.trim(:leading<0>); > > > > $string.trim(:trailing<0>); > > Alternatively, those could be ltrim() and rtrim(). 'left' and 'right' are probably not the right name

Re: [PATCH] Add .trim method

Ovid wrote: $string.trim(:leading<0>); $string.trim(:trailing<0>); Setting leading or trailing to false (they default to true) would result in either leading or trailing whitespace not being trimmed Alternatively, those could be ltrim() and rtrim(). If you need to dynamically de

Re: [PATCH] Add .trim method

- Original Message > From: Larry Wall > On Mon, Jan 12, 2009 at 05:04:50AM -0800, Ovid wrote: > : ...the trivial $string.trim and trim($string) case. > > Hmm, I'd think .trim should work like .chomp, and return the trimmed > string without changing the original. You'd use $str.=trim t

Re: [PATCH] Add .trim method

On Mon, Jan 12, 2009 at 9:01 AM, Ovid wrote: > - Original Message > > > > > > I could optionally make the following work: > > > > > > > > $string.trim(:leading<0>); > > > > $string.trim(:trailing<0>); > > Alternatively, those could be ltrim() and rtrim(). If you need to > dynamically d

Re: [PATCH] Add .trim method

On 2009-01-12 Ovid wrote: > Um, er. Damn. Now I'm wondering how my "leading" and "trailing" > trimming works with Hebrew. How are the strings implemented > internally? RTL (and bidi) languages are written in strings so that the character order is the logical, reading, order. That is, the chara

Re: [PATCH] Add .trim method

- Original Message > From: jesse > > On Mon, Jan 12, 2009 at 07:01:25AM -0800, Ovid wrote: > > > > > I could optionally make the following work: > > > > > > > > > > $string.trim(:leading<0>); > > > > > $string.trim(:trailing<0>); > > > > Alternatively, those could be ltrim() and rtri

Re: [PATCH] Add .trim method

- Original Message > From: Aristotle Pagaltzis > * Austin Hastings [2009-01-12 22:00]: > > How about .trim(:l, :r) with both as the default? > > Liveable. I've just committed the pugs tests for trim. However, it's just 'trim' with no left/right, leading/trailing, Catholic/Protestant

Re: [PATCH] Add .trim method

* Austin Hastings [2009-01-12 22:00]: > How about .trim(:l, :r) with both as the default? Liveable. > And if the rtl crowd makes a furor, we can add :a/:o or :ת/:א > or something. *grin* Maybe :h and :t (head/tail). > Useful for doing infrequent things. IMO, left and right > trimming are inf

Re: [PATCH] Add .trim method

* Ovid [2009-01-12 22:05]: > I see your point And now I see yours. I was visualising the memory layout of a string, wherein a right-to-left string gets displayed from the right end of it’s in-memory representation so “left” and “right” are absolutes in that picture. But of course RTL reverses the

Re: [PATCH] Add .trim method

* Larry Wall [2009-01-12 21:55]: > * Aristotle Pagaltzis [2009-01-12 21:20]: > > Plus if there are separate `.ltrim` and `.rtrim` functions it > > would be better to implement `.trim` by calling them rather > > than vice versa, so it wouldn’t even be less efficient two > > make two calls rather t

Re: [PATCH] Add .trim method

Now to answer your question, *I* know where the *left* side is in > a string that runs from right to left: it’s at the *left*, same > as if the string ran from the left to the right, because left is > at the *left*. > > :-) I see your point, but it complicates the internals of the

Re: [PATCH] Add .trim method

Aristotle Pagaltzis wrote: Actually that makes me wonder now whether it’s actually a good idea at all to make the function parametrisable at all. Even `.ltrim.rtrim` is shorter and easier than `.trim(:start,:end)`! How about .trim(:l, :r) with both as the default? And if the rtl crowd makes

Re: [PATCH] Add .trim method

On Mon, Jan 12, 2009 at 09:18:03PM +0100, Aristotle Pagaltzis wrote: : Plus if there are separate `.ltrim` and `.rtrim` functions it : would be better to implement `.trim` by calling them rather than : vice versa, so it wouldn’t even be less efficient two make two : calls rather than a parametrised

Re: [PATCH] Add .trim method

* Ovid [2009-01-12 21:20]: > Since that's RTL (Right To Left) text, should ltrim remove the > leading or trailing whitespace? > > I like Jonathan's trim_start and trim_end. Let me ask you first: does a string that runs Right-to-Left start at the left and end at the right or start at the right and

Re: [PATCH] Add .trim method

* Aristotle Pagaltzis [2009-01-12 20:55]: > Also `:!start` to imply `:end` unless `:!end` (which in turn > implies `:start` unless `:!end`)? Ugh, forget this, I was having a blank moment. Actually that makes me wonder now whether it’s actually a good idea at all to make the function parametrisab

Re: [PATCH] Add .trim method

- Original Message > Also `:!start` to imply `:end` unless `:!end` (which in turn > implies `:start` unless `:!end`)? > > I’d like not to have to type `.trim(:start)` when I could just do > `.ltrim` though. So what would .ltrim do with this? " בָּרוּךְ שֵׁם כְּבוֹד מַלְכוּתוֹ לְע

Re: [PATCH] Add .trim method

On Mon, Jan 12, 2009 at 2:50 PM, Aristotle Pagaltzis wrote: > I'd like not to have to type `.trim(:start)` when I could just do > `.ltrim` though. As long as we gloss .ltrim as "leading" trim rather than "left" trim. Then the other end could be .ttrim for "trailing"? We really ought to avoid usi

Re: [PATCH] Add .trim method

* Ovid [2009-01-12 18:40]: > 1. No params, trim all > 2. :start or :end, only trim that bit (not a negated option :) > 3. If both, goto 1 Also `:!start` to imply `:end` unless `:!end` (which in turn implies `:start` unless `:!end`)? I’d like not to have to type `.trim(:start)` when I could ju

Re: [PATCH] Add .trim method

would be faster than the regex method of trimming? -Andy

Re: [PATCH] Add .trim method

On Mon, Jan 12, 2009 at 09:33:32AM -0800, Geoffrey Broadwell wrote: : That of course raises the question of how one *would* properly override : trim's concept of whitespace Well, given that .trim is essentially just .comb(/\S.*\S/), which in turn is really just m:g/(\S.*\S)/, I don't see much

Re: [PATCH] Add .trim method

- Original Message > From: Geoffrey Broadwell > When I saw your proposed syntax above, instead of reading "don't trim > leading/trailing whitespace", I read "change the definition of > 'whitespace' to 'codepoint 0' for leading/trailing". > > That of course raises the question of how on

Re: [PATCH] Add .trim method

- Original Message > >> Agreed, but ltrim and rtrim will disappoint Israelis and dyslexics alike. > >> Suggestions welcome as I can't think of anything better. > > > > The .Net framework calls 'em TrimStart and TrimEnd (and has a Trim that does > > both). So maybe trim_start and trim_en

Re: [PATCH] Add .trim method

On Mon, 2009-01-12 at 07:01 -0800, Ovid wrote: > - Original Message > > > > > > I could optionally make the following work: > > > > > > > > $string.trim(:leading<0>); > > > > $string.trim(:trailing<0>); > > Alternatively, those could be ltrim() and rtrim(). If you need to > dynamica

Re: [PATCH] Add .trim method

Jonathan (>), Ovid (>>), Larry (>>>): >>> Can't say I really like the negated options though. They smell funny. >> >> Agreed, but ltrim and rtrim will disappoint Israelis and dyslexics alike. >> Suggestions welcome as I can't think of anything better. > > The .Net framework calls 'em TrimStart an

Re: [PATCH] Add .trim method

Ovid wrote: - Original Message In the pir, doesn't the "s = self" line copy self, thus ensuring that I'm changing "s" and not "self"? No, it's binding. Or do I need "s = clone self" (or however it's written). Yeah, but also note that substr would return a copy... Can't sa

Re: [PATCH] Add .trim method

On Mon, Jan 12, 2009 at 05:04:50AM -0800, Ovid wrote: : ...the trivial $string.trim and trim($string) case. Hmm, I'd think .trim should work like .chomp, and return the trimmed string without changing the original. You'd use $str.=trim to do it in place. Can't say I really like the negated optio

Re: [PATCH] Add .trim method

Aristotle Pagaltzis wrote: * Ovid [2009-01-12 16:05]: Or all could be allowed and $string.trim(:leading<0>) could all $string.rtrim internally. ++ Note you can write it :!leading too. :-) Jonathan

Re: [PATCH] Add .trim method

* Ovid [2009-01-12 16:05]: > Or all could be allowed and $string.trim(:leading<0>) could all > $string.rtrim internally. ++ Regards, -- Aristotle Pagaltzis //

Re: [PATCH] Add .trim method

- Original Message > > > I could optionally make the following work: > > > > > > $string.trim(:leading<0>); > > > $string.trim(:trailing<0>); Alternatively, those could be ltrim() and rtrim(). If you need to dynamically determine what you're going to trim, you'd couldn't just set va

Re: [PATCH] Add .trim method

- Original Message > > =item trim > > > > our Str multi Str::trim ( Str $string ) > > > > Removes leading and trailing whitespace from a string. > > > > =cut > > > > I could optionally make the following work: > > > > $string.trim(:leading<0>); > > $string.trim(:trailing<0>); >

Re: [PATCH] Add .trim method

Ovid (>): > =item trim > > our Str multi Str::trim ( Str $string ) > > Removes leading and trailing whitespace from a string. > > =cut > > I could optionally make the following work: > > $string.trim(:leading<0>); > $string.trim(:trailing<0>); > > Setting leading or trailing to false (the

Re: [PATCH] Add .trim method

- Original Message > From: Ovid > > This patch implements the .trim() method for strings. > > Now that I'm reading S29, I see there is no .trim() method there. I got that > because it was referenced in pugs in the cookbook (not in tests, though) and >

Re: new method question

Moritz Lenz moritz-at-casella.verplant.org |Perl 6| wrote: Attributes need to have a twigil, so it would be has $.name The syntax has $name; with no twigil is legal according to S12. Perhaps the original poster (Xiao Yafeng) might like to read

Re: new method question

Xiao Yafeng wrote: > There are no barewords in Perl 6, but it seems new method is an exception: > > class Dog { > > has $name; Attributes need to have a twigil, so it would be has $.name > method bark () { > say $name; >

new method question

There are no barewords in Perl 6, but it seems new method is an exception: class Dog { has $name; method bark () { say $name; } } my $p = Dog.new($name => 'boo'); $p.bark;#error! my $p = Dog.new(

Re: syntax question: "method close is export ()"

On Tue, Aug 05, 2008 at 05:43:57PM +0800, Audrey Tang wrote: > John M. Dlugosz 提到: >> Does that mean that traits can come before the signature? Or should it >> be corrected to >> method close () is export { ... } > > It's a simple typo. Thanks, fixed in r1457

Re: syntax question: "method close is export ()"

John M. Dlugosz 提到: Does that mean that traits can come before the signature? Or should it be corrected to method close () is export { ... } It's a simple typo. Thanks, fixed in r14572. Cheers, Audrey

syntax question: "method close is export ()"

Does that mean that traits can come before the signature? Or should it be corrected to method close () is export { ... } ?

Re: method hiding (or not) in derived classes

nce there might not be a unique next method on the target list and a nextsame might fail. I agree that the synopsis conflate these details into the term "candidate list". But I hope you are more rigorous. What about ordinary methods (and ordinary parameters of multis)? Does the candida

Re: method hiding (or not) in derived classes

semicolon parameters, compare the actual type and drop out of the list if any don't match. When you drop those candidates that "can never match" is mostly a matter of optimization, I suspect. : What about ordinary methods (and ordinary parameters of multis)? Does the candidate li

Re: method hiding (or not) in derived classes

ore, there is a list. What about ordinary methods (and ordinary parameters of multis)? Does the candidate list hold every method name that matches, or does it do simpler parameter matching based on number of arguments, required named arguments, etc.? There is hopefully a complete specific

Re: method hiding (or not) in derived classes

y. That is what the semicolons are for. And even if a candidate is voted out it still can vote out others. What about ordinary methods (and ordinary parameters of multis)? Does the candidate list hold every method name that matches, or does it do simpler parameter matching based on number of argum

method hiding (or not) in derived classes

ist if any don't match. What about ordinary methods (and ordinary parameters of multis)? Does the candidate list hold every method name that matches, or does it do simpler parameter matching based on number of arguments, required named arguments, etc.? If that is the case, then a derived m

Re: but semantics (was Re: Naming the method form of s///)

On Mon, Sep 11, 2006 at 11:12:00AM -0700, Larry Wall wrote: : On Mon, Sep 04, 2006 at 08:54:02PM +0200, TSa wrote: : : But are assignment ops allowed as initializer? : : : : my $z = $p but= { .y = 17 }; : : Why not? It's only the first = that's potentially special. (And it's : only for non-my

Re: but semantics (was Re: Naming the method form of s///)

On Mon, Sep 04, 2006 at 08:54:02PM +0200, TSa wrote: : But are assignment ops allowed as initializer? : : my $z = $p but= { .y = 17 }; Why not? It's only the first = that's potentially special. (And it's only for non-my, since my's = is an ordinary assignment at normal run time.) I don't see

Re: multi method dispatching of optional arguments (further refined)

On Mon, Sep 04, 2006 at 10:52:35PM -0700, Trey Harris wrote: : In a message dated Tue, 5 Sep 2006, Ph. Marek writes: : >I now had a look at http://dev.perl.org/perl6/doc/design/syn/S06.html : >but didn't find what I meant. Sorry if I'm just dumb and don't : >understand you (or S06); I'll try to e

  1   2   3   4   5   >