is is overoverloaded?

[Piers Cawley]

Luke Palmer <fibo...@babylonia.flatirons.org> writes:

> While my last post was about removing entities, this one will be about
> adding them.
>
> Now, I don't know what Larry has up his sleeve in this respect, but as
> I see it now, C<is> is too heavily overloaded. As it stands, it means
> 3 things:
>
> (1) Attributing traits
> (2) Inheriting base classes
> (3) "Tying" variables

But in all three cases, C<is> is being used to set a trait on a
container. Here's my take on what happens during an 'is' set up:

my $foo is Bar(baz);

is equivalent to:

given \$foo {
.ADD_TRAIT(Bar, baz);
}

class Foo is Base {...}

becomes (sort of) equivalent to:

given Class.new('Foo') {
.ADD_TRAIT(Base);
.ADD_TRAIT(definition, {...});
}

If we have the definitions

# Assuming *everything* inherits from object...
multi ADD_TRAIT (Object $self is rw: Object $trait, *@args) {
$trait.can('ADD_TRAIT_TO') ?? $trait.ADD_TRAIT_TO($self, *@args)
:: $self.prop($trait, @args);
}

multi ADD_TRAIT (Class $self is rw: Class $trait) {
$self.add_base_class($trait);
}

class Tie::Scalar {
classmethod ADD_TRAIT_TO ($target is rw, *@args) {
$target = .new.TIESCALAR(*@args);
}

method TIESCALAR {...}
method FETCH {...}
method STORE ($newval) {...}
method CLEAR {...}
}

The details are almost certainly wrong, but the important thing to
remember is that a Class is just another container with slightly
different semantics for handling its traits...

--
Piers

[Luke Palmer]

Piers wrote:
> Luke Palmer <fibo...@babylonia.flatirons.org> writes:
>
> > While my last post was about removing entities, this one will be about
> > adding them.
> >
> > Now, I don't know what Larry has up his sleeve in this respect, but as
> > I see it now, C<is> is too heavily overloaded. As it stands, it means
> > 3 things:
> >
> > (1) Attributing traits
> > (2) Inheriting base classes
> > (3) "Tying" variables
>
> But in all three cases, C<is> is being used to set a trait on a
> container. Here's my take on what happens during an 'is' set up:

[snip]

> The details are almost certainly wrong, but the important thing to
> remember is that a Class is just another container with slightly
> different semantics for handling its traits...

Multimethods fit the implementation bill rather nicely.
Unfortunately, I wasn't talking about implementation (Our p6i team is
super-competent). I think the I<language> is too ambiguous.

My primary concern is with the

class Foo is Bar { }

syntax, being ambiguous with attributing a trait on the class. If
classes themselves can't have traits... okay. But I think they
should, and that it should be distinct from inheritance, seeing as
classes are "first-class objects" now.

And I don't want it to depend on whether Bar was declared a class or a
trait.

Also, this syntax (which we mortals came up with, with no conformation
from the design gods) would pose a problem:

class Baz ::= Foo is Bar;

Then the first definition could I<also> be confused with attributing a
trait on every instance of a Foo class, rather than the class itself.

But, this is all A12, and we're not even to 8. So, I'll hold off for
now, and see what cognitive magic Larry & co. come up with for this
syntax (if it stays).

Luke