[Reposting this from earlier this week, since it didn't seem to make it to
the news server. -dmw]
A question about the calling syntax of named parameters versus arguments
supplied to a slurpy hash. If I understand A6 and A12 correctly, all Pair
arguments to a function (sub, method, etc.) are
Larry Wall [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
On Wed, May 05, 2004 at 04:25:45PM -0400, Austin Hastings wrote:
:
: method x ($me: $req, ?$opt, +$namedopt, *%named, [EMAIL PROTECTED]) {...}
: vs:
: method x($me: $req, ?$opt, ~$namedopt, *%named, [EMAIL
On Thu, 2004-05-06 at 02:36, Dov Wasserman wrote:
After the New And Improved logError() routine is rolled out, it seems to me
that this log statement should generate a compile-time error, since the
named Int parameter prio is given a non-integer argument HIGH. At best,
this should be a
Aldo Calpini [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On Thu, 2004-05-06 at 02:36, Dov Wasserman wrote:
After the New And Improved logError() routine is rolled out, it seems to
me
that this log statement should generate a compile-time error, since the
named Int parameter
On Thu, 2004-05-06 at 02:36, Dov Wasserman wrote:
To distinguish these two cases, what if we used the := binding operator to
bind an argument to a named parameter:
logError($err_msg, prio := 3);
but how would this look like to a subroutine that is not defined to
accept a named parameter
On Wed, 2004-05-05 at 22:36, Dov Wasserman wrote:
sub logError($msg, Int +$prio = 4, *%errorInfo) {
[...]
logError(Database error, module = DB.pm, line = 263, prio = HIGH);
After the New And Improved logError() routine is rolled out, it seems to me
that this log statement should generate a
There's a subtle problem / feature resulting from the is rw trait that
may be so obvious that I'm making a fool of myself, or it might be that
it's not yet occurred, but I don't recall seeing discussion of it.
The simple case is:
sub foo(X $i is rw) {...}
class X {...}
On Thu, 2004-05-06 at 10:39, Aaron Sherman wrote:
The simple case is:
sub foo(X $i is rw) {...}
class X {...}
class Y {...}
my Y $var = 'something';
foo($var);
In this case, something kind of interesting has to happen.
Either the signature checking has
On Mon, Apr 19, 2004 at 01:06:29AM -0600, Luke Palmer wrote:
: Therefore, the first syntax can be redefined to evaluate the code block
: and assign the result to $0. The example now becomes:
:
: rule list {
: ?term , ?list { make_node('list', $?term, $?list) }
: | ?term
At 10:44 AM -0700 5/6/04, chromatic wrote:
On Thu, 2004-05-06 at 10:39, Aaron Sherman wrote:
The simple case is:
sub foo(X $i is rw) {...}
class X {...}
class Y {...}
my Y $var = 'something';
foo($var);
In this case, something kind of interesting has to
On Thu, May 06, 2004 at 01:52:45PM -0400, Dan Sugalski wrote:
: At 10:44 AM -0700 5/6/04, chromatic wrote:
: On Thu, 2004-05-06 at 10:39, Aaron Sherman wrote:
:
: The simple case is:
:
: sub foo(X $i is rw) {...}
: class X {...}
: class Y {...}
: my Y $var = 'something';
:
At 11:03 AM -0700 5/6/04, Larry Wall wrote:
On Thu, May 06, 2004 at 01:52:45PM -0400, Dan Sugalski wrote:
: At 10:44 AM -0700 5/6/04, chromatic wrote:
: On Thu, 2004-05-06 at 10:39, Aaron Sherman wrote:
:
: The simple case is:
:
: sub foo(X $i is rw) {...}
: class X {...}
:
On Thu, 2004-05-06 at 11:24, Dan Sugalski wrote:
Well... sort of, but only because you've defined that for perl 6
classes automatically do themselves--you've conflated inheritance and
interface. Which is fine, except that it falls down in the face of
objects from classes that don't do
Aldo Calpini [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
if you decide to reimplement logError to be just:
sub logError {# implicit ([EMAIL PROTECTED])
# ...
}
using a Pair, you still have someting (a Pair object) that you can
inspect,
At 11:42 AM -0700 5/6/04, chromatic wrote:
On Thu, 2004-05-06 at 11:24, Dan Sugalski wrote:
Well... sort of, but only because you've defined that for perl 6
classes automatically do themselves--you've conflated inheritance and
interface. Which is fine, except that it falls down in the face of
Dov Wasserman wrote:
My concern is that given an argument supplied as a pair (foo = bar), it
is not clear which type of parameter is meant to be supplied. If there is no
such named parameter, we know that the argument was intended for the slurpy
hash. However, what if the method designer later
-Original Message-
From: chromatic [mailto:[EMAIL PROTECTED]
Given:
- class A, a superclass
- class AB, a subclass of A
- class Eh, a class that does A but does not inherit
from it
- subroutine signature foo(A some_object)
If the signature
On Thu, 2004-05-06 at 13:27, Austin Hastings wrote:
I think we had this discussion a year or two ago, and Damian was opposed to
the notion that providing the correct methods was equivalent to providing
the interface or belonging to the class.
His reasoning involved Dog and Tree both sharing
-Original Message-
From: chromatic [mailto:[EMAIL PROTECTED]
Sent: Thursday, 06 May, 2004 04:36 PM
To: Austin Hastings
Cc: Perl6 Language List
Subject: RE: is rw trait's effect on signature
On Thu, 2004-05-06 at 13:27, Austin Hastings wrote:
I think we had this discussion a
On Thu, 2004-05-06 at 13:47, Austin Hastings wrote:
Then in your example:
The class 'Eh' does A but does not inherit, did you mean:
class Eh {
method A1
method A2
method A3
}
Yes.
I had thought that Cdoes CLASS (class implicitly= role) had been
rejected.
I don't remember in
20 matches
Mail list logo
