On Sat, Dec 04, 2004 at 03:28:12PM -0800, Ashley Winters wrote:
: On Sat, 4 Dec 2004 11:15:14 -0800, Larry Wall <[EMAIL PROTECTED]> wrote:
: > On Sat, Dec 04, 2004 at 10:25:49AM -0700, Luke Palmer wrote:
: > : But this convention provides much more accuracy than memorizing a list
: > : of methods t
Larry Wall writes:
> : But this convention provides much more accuracy than memorizing a list
> : of methods that don't automatically thread, or memorizing a list of
> : iterator methods that act on the iterator and not its current value.
>
> Except that you don't actually have to memorize a list.
On Sat, 4 Dec 2004 11:15:14 -0800, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Sat, Dec 04, 2004 at 10:25:49AM -0700, Luke Palmer wrote:
> : But this convention provides much more accuracy than memorizing a list
> : of methods that don't automatically thread, or memorizing a list of
> : iterator met
The only reason a tied()-like operator works is that it's not really
a run-time operator at all.
: Anyway, there's something to think about. Moving on...
:
: > The answer is simple enough: for scalar container method calls, use
: > $foo.\bar(), which would be syntactic sugar for (\$foo).b
is a mouthfull, but let's see you do that *at all*
with the other semantics.
Anyway, there's something to think about. Moving on...
> The answer is simple enough: for scalar container method calls, use
> $foo.\bar(), which would be syntactic sugar for (\$foo).bar, and would
&
od conflict
between container methods and value methods should be obvious. What
should ((1|2)|(3&4)).values return?
The answer is simple enough: for scalar container method calls, use
$foo.\bar(), which would be syntactic sugar for (\$foo).bar, and would
be the Perl6 equivalent to the Perl5 idiom
