HaloO,
John M. Dlugosz wrote:
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
multi infix:<=> (Any $lhs, A $rhs)
{
$lhs.STORE($rhs.clone); # or .cow if that's not automatic
}
$lhs.VAR.STORE.
I guess I also forgot the is rw to get a binding to the caller's
container not
HaloO,
Daniel Ruoso wrote:
[ I'm using this message to reply, because I didn't receive your
reply... I'm taking it from the list history... There really seems to be
something wrong with this list... ]
I see all your messages arrive twice.
This is not specced apparently to leave room for dec
Ter, 2008-04-29 às 14:21 +0200, TSa escreveu:
> Daniel Ruoso wrote:
> > Not really... 'does' is a composition operation, 'realises' would be
> > just a type annotation that doesn't change the actual composition.
> OK, but that is not in the spec yet. To me that is like the
> proposed 'like' operato
[ I'm using this message to reply, because I didn't receive your
reply... I'm taking it from the list history... There really seems to be
something wrong with this list... ]
TSa wrote:
> BTW, is WHICH globally unique? Or is that also an
> implementation detail?
This is not specced apparently to
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
multi infix:<=> (Any $lhs, A $rhs)
{
$lhs.STORE($rhs.clone); # or .cow if that's not automatic
}
$lhs.VAR.STORE.
My readings have been that = just copies the ref. Unless it's a "value
type" or "immutable" which just means
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
HaloO,
Daniel Ruoso wrote:
Not really... 'does' is a composition operation, 'realises' would be
just a type annotation that doesn't change the actual composition.
OK, but that is not in the spec yet. To me that is like the
proposed 'like' opera
HaloO,
Daniel Ruoso wrote:
So...
class A { has $.a; method inc { $.a++ } };
$a = A.new( a => 0);
$b = $a;
$b.inc();
$a.inc();
say $a.a; # 2
say $b.a; # 2
Will work as expected.
Depends a bit on one's expectations :)
So infix:<=> has shallow copy semantics.
HaloO,
Daniel Ruoso wrote:
Not really... 'does' is a composition operation, 'realises' would be
just a type annotation that doesn't change the actual composition.
OK, but that is not in the spec yet. To me that is like the
proposed 'like' operator but with the programmer taking full
responsibi
Ter, 2008-04-29 às 11:54 +0200, TSa escreveu:
> > If we are to define an operator to declare that some arbitrary object
> > conforms to some API, I would think the following as saner...
> > sub foo(Point $p) {...};
> > FoxPoint $fp = ...;
> > $fp realises Point;
> > foo($fp);
> Here the spec is q
Ter, 2008-04-29 às 09:28 +0200, TSa escreveu:
> The thing is the .^does traverses the meta information
> to find the *named* concept Point. The FoxPoint in John's
> example doesn't have that and thus nominally fails the
> Point test. The idea is now to also have
.^does *might* traverse the infor
HaloO,
Daniel Ruoso wrote:
.^does *might* traverse the information as well as simply return true if
the object says so.
Let's not regard the problem of meta level interoperation for now.
That is we have *one* meta level. The spec says that .^does asks
this meta system. Now the meta system does
HaloO,
Daniel Ruoso wrote:
hrmm... I might just be overlooking something... but...
sub foo (Point $p) {...}
means...
$signature ~~ $capture
means...
Point $p := $capture[0]
means...
$capture[0] ~~ Point
means...
$capture[0].^does(Point)
The thing is the .^does traverses the meta info
Seg, 2008-04-28 às 10:15 -0700, Jon Lang escreveu:
> Ah; that clears things up considerably. If I understand you
> correctly, John is using '£' to mean "use Duck Typing here". _That_,
> I can definitely see uses for.
hrmm... I might just be overlooking something... but...
sub foo (Point $p) {.
13 matches
Mail list logo
