Aaron pointed out:
> But, in terms of constants, it seems to me that there's no
> difference. They both have only one value that is assigned
> when the module/class is parsed.
Well, in *practice* there's no difference, but in their mystical essences,
they're completely different. ;-)
> but from this thread it looks like you and larry are still hammering out
> the details. :) maybe a revision of A3/E3 will be in the offing (like
> larry's retraction of dropping <>).
That's entirely possible. The Perl 6 Ministry of Truth is forever on the
look-out for Revisionist Her
> For a typed subroutine with named parameters, is the declaration syntax
> (sans property declaration) going to be:
>
>'sub' type ident '(' paramlist ')' block
>
> (in, say, Parse::RecDescent)? I'm thinking about how to add subroutines
> to BabyPerl*, and I need to k
On Tue, Oct 30, 2001 at 09:59:49AM +1100, Damian Conway wrote:
>
>> > class Demo {
>> > my $threshold is const = 100;
>>
>> Hmm... is a "my const" the same as an "our const"?
>
> No. 'my' is per-instance; 'our' is per-class.
But, in terms of constants, i
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> Uri wrote:
>> that clears it up. so the key/value named params get converted to scalar
>> args in INIT with the same name. is this in any of the current exegeses?
>> or will sub calls be covered in the apocalyptic future?
DC>
Uri wrote:
> that clears it up. so the key/value named params get converted to scalar
> args in INIT with the same name. is this in any of the current exegeses?
> or will sub calls be covered in the apocalyptic future?
A3/E3 covered named arguments. The only additional bit here is that
For a typed subroutine with named parameters, is the declaration syntax
(sans property declaration) going to be:
'sub' type ident '(' paramlist ')' block
(in, say, Parse::RecDescent)? I'm thinking about how to add subroutines
to BabyPerl*, and I need to know if I'm at least right about
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> Uri asked:
DC> method INIT ( $fooval, $barval) {
>>
>> where is the binding from the keys below to the INIT params? surely (and
>> yes, i am calling you shirley) you don't mean that 'bar' is converted or
>> mapped to $barva
On Tue, Oct 30, 2001 at 12:27:32PM +1100, Damian Conway wrote:
>> > PS: I'd just like to point out that people gasped in horror when
>> > I presented this idea at YAPC::NA::2001 as part of the
>> > (soon-to-be-released) Klingon binding of Perl. ;-)
>>
>> I'll add my ow
John observed:
> Whatever filter he's running his thoughts through, I'm pretty
> sure it's lossy... ;)
For which mercy you should probably be extremely grateful. ;-)
Damian
> Does this mean that the caller of a multimethod has to know he calls a
> multimethod (as oposed to a regular method). Should not the user of a
> library spared from such implementation details, however sexy they are?
One might well argue the same thing about calling normal subroutines
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'
At 12:27 PM 10/30/2001 +1100, Damian Conway wrote:
>> > PS: I'd just like to point out that people gasped in horror when
>> > I presented this idea at YAPC::NA::2001 as part of the
>> > (soon-to-be-released) Klingon binding of Perl. ;-)
>>
>> I'll add my own, now.
>
>nu
On Mon, 29 Oct 2001, Michael G Schwern wrote:
> On Tue, Oct 30, 2001 at 11:27:39AM +1100, Damian Conway wrote:
> > The $64K question then being: can I call it like so:
> >
> > ($obj1, $obj2)->foo(@args);
>
> Is that merely sugar for:
>
> # errr, $_.foo(@args) ?
> $_->foo(@args) for
> > ($obj1, $obj2)->foo(@args);
>
> Is that merely sugar for:
>
> # errr, $_.foo(@args) ?
> $_->foo(@args) foreach($obj1, $obj2);
No. What you showed would be achieved with either a hyperoperation:
($obj1, $obj2)^.foo(@args);
or a superposition:
On Tue, Oct 30, 2001 at 11:27:39AM +1100, Damian Conway wrote:
> The $64K question then being: can I call it like so:
>
> ($obj1, $obj2)->foo(@args);
Is that merely sugar for:
# errr, $_.foo(@args) ?
$_->foo(@args) foreach($obj1, $obj2);
or is there something more interesting goi
> : Um, can we be even more clear? What does the following do?
> :
> : method foo ($atc, $btc: $ctc, $dtc, $etc) {...}
> :
> : Is that an error?
>
> Multimethod dispatch on two objects?
The $64K question then being: can I call it like so:
($obj1, $obj2)->foo(@a
[EMAIL PROTECTED] writes:
: On Tue, Oct 30, 2001 at 09:39:03AM +1100, Damian Conway wrote:
: > Okay, so let's clarify:
: >
: > 1. If you declare a method *with* a colon separator in its parameter
: >list:
: >
: > method foo ($self: $foosrc, $foodest, $etc) {...}
:
: Um,
[EMAIL PROTECTED] writes:
: Larry revealed:
:
:> :method bar($me : *@_) {
:> :...
:> :}
:> :
:> : will use $me instead.
:>
:> That is the approach I currently favor. (Though I'd probably leave
:> out the space in front of the colo
> > class Demo {
> > my $threshold is const = 100;
>
> Hmm... is a "my const" the same as an "our const"?
No. 'my' is per-instance; 'our' is per-class.
> If so, does this mean that there will be no such thing as a
> C++-style const (constant per in
Sam asked:
> are there any plans in Perl 6 for specifying
> OO <-> RDBMS mapping in the class { } construct? Another way to look at
> this would be adding arbitrary fine grained type constraints to
> attributes, and then tools can be written which examine these constraints
> and
On Tue, Oct 30, 2001 at 09:39:03AM +1100, Damian Conway wrote:
> Okay, so let's clarify:
>
> 1. If you declare a method *with* a colon separator in its parameter
> list:
>
> method foo ($self: $foosrc, $foodest, $etc) {...}
Um, can we be even more clear? What does
> Ick. I don't want to lose the dots that visually distinguish instance
> variables from ordinary lexicals, and simultaneously render the extra
> bracketing and indentation unnecessary. I'd write the above as:
>
> class Demo;
>
> my $.foo is public;
> my $.
Damian Conway:
# Larry revealed:
#
#> :method bar($me : *@_) {
#> :...
#> :}
#> :
#> : will use $me instead.
#>
#> That is the approach I currently favor. (Though I'd
# probably leave
#> out the space in front of the colon.) And it
[EMAIL PROTECTED] writes:
: > method INIT ($fooval, $barval)
: > {
: > $.foo = $fooval;
: > $.bar = $barval;
: > }
:
: (sorry, couldn't help fixing the braces... ;)
I don't really care where you put the initial brace, as long as you
outdent the closing brace. My personal brace sty
Brent Dax writes:
: Are we still gonna be able to pick what we call the current instance?
: From previous programming languages, I'm a lot more comfortable with $me
: or $this than $self. (Yeah, it's a little thing, but it's something I
: *liked* about Perl 5's OO--it showed how you had flexibili
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 a
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
[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?
Larry
[EMAIL PROTECTED] writes:
: Aaron wrote:
:
:> Several questions come up.
:>
:>* If $.foo is "like" the Perl5 $self->{foo},
:
: Except (as I'm sure you know) that Perl 6 class instantiations aren't
: hashes, and their attributes aren't hash entries.
Nevertheless, *using* one as a
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
From: Sam Vilain [mailto:[EMAIL PROTECTED]]
>
> It would be a bit like Class::Contract merged with
> Class::Tangram, but if Class::Contract is going into
> the core then it's a feature I'd like to see...
I'd like to see Class::Contract play nicely with Class::Tangram,
Class::Multimethods, etc.
On Mon, Oct 29, 2001 at 03:03:58PM +, Dave Mitchell wrote:
> As to whether other uses of %MY:: are Good Things, see previous discussions
> ad nauseum on -internals and -language.
Ok, sorry. I didn't mean to resurect an old, tired thread.
I'm sure clear heads will prevail and some precaution
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> > If it's an outer-scope lexical, use C{MY}>
>
> Ok, I'm all over the nice new features of Perl6, but darnit,
> "upvar" is one of the primary reasons that TCL is unusable. Please,
> let's not soften the walls of lexical scope. They're there for a
> reaso
On Mon, Oct 29, 2001 at 11:57:47AM +1100, Damian Conway wrote:
> AJS> How would this play with constants?
>
> class Demo {
> my $threshold is const = 100;
Hmm... is a "my const" the same as an "our const"? If so, does this mean
that there will be no such thing as a C++-s
On Mon, Oct 29, 2001 at 11:03:33AM +1100, 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.
This seems wise. Very Perlish.
> If it's an outer-scope lexical, use C{MY}>
On Mon, 29 Oct 2001 11:03:33 +1100 (EST)
Damian Conway <[EMAIL PROTECTED]> wrote:
> The Real Damian is the Damian inside each of us.
> You need to get in touch with your *own* inner Damian.
SETTING: Trendy bar.
DC: Hey, beautiful, how's it going? Say, do you have a little Damian in
you?
> "BD" == Brent Dax <[EMAIL PROTECTED]> writes:
BD> Uri Guttman:
BD> # DC> class Demo {
BD> # DC> my $foo;
BD> # DC> my $bar;
BD> #
BD> # DC> method INIT ( $fooval, $barval) {
BD> # DC> $fo
38 matches
Mail list logo
