Newsgroups: perl.perl6.language
Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.stanford.edu!nntp.perl.org
Return-Path: <Austin_Hasti...@yahoo.com>
Mailing-List: contact perl6-language-h...@perl.org; run by ezmlm
Delivered-To: mailing list perl6-langu...@perl.org
Delivered-To: perl6-langu...@perl.org
Reply-To: <Austin_Hasti...@Yahoo.com>
To: "Perl6" <perl6-langu...@perl.org>
Subject: RE: enums and bitenums
Date: Fri, 12 Dec 2003 17:24:51 -0500
Message-ID: <ICELKKFHGNOHCNCCCBKFEEKACIAA.Austin_Hastings@Yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain;	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <20031212184405.GA5131@wall.org>
X-Spam-Check-By: one.develooper.com
X-Spam-Status: No, hits=-0.5 required=7.0 tests=CARRIAGE_RETURNS,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03,USER_AGENT_OUTLOOK version=2.44
X-SMTPD: qpsmtpd/0.26, http://develooper.com/code/qpsmtpd/
Approved: n...@nntp.perl.org
From: Austin_Hasti...@Yahoo.com (Austin Hastings)
References: <20031212184405.GA5131@wall.org>
Lines: 156



> -----Original Message-----
> From: Larry Wall [mailto:la...@wall.org]
> Sent: Friday, December 12, 2003 1:44 PM
>


> Potentially, though roles are more properly thought of as types
> than classes.
> That is, they're abstract sets of values.  You can instantiate
> one sufficiently
> well to take a reference to it, so that you can do
>
>     $someobject but= $somerole;
>
> But it's not really an object in its own right, and it's not clear that
> you can call any of the methods it defines unless it's part of an object.

Presumably it will share whatever behavior Classes use to provide "static"
methods?

> : Then assuming that certain objects "inherit" certain roles, you could
> : use something like the Perl 5 $self->SUPER::new() syntax.  Only it would
> : look more like this:
> :
> :     $foo->Boolean.true
> :     $bar->Color.red
> :     $baz->Int.byte
>
> Well, we can't use -> because we're using that for something else.
> But it's certainly true that we'll have to have some mechanism for
> disambiguating Color.green from Blackberry.green.  After all,
>
>     Blackberry.green == Color.red
>
> Or maybe it's
>
>     Blackberry::green == Color::red
>
> I'm not sure how subtypes are related to types yet, syntactically
> speaking.
> Might even be
>
>     Blackberry[green] == Color[red]

This syntax suggests a javascript-like similarity between classes (or
objects) and arrays. Do you want that?
Perhaps pretending hashiness would be truer to both Perl's roots and the
syntax used to construct things:

  my &member_function = \Class{memberfunction};

  Blackberry{green} == Color{green}


> : > Another implication is that, if properties are subtypes, we can't use
> : > the same name as a cast method.  Since
> : >
> : >     $baz.Byte
> : >
> : > only returns true or false, we'd need something like (yuck)
> : >
> : >     $baz.asByte
> : [...or...]
> : >     $baz.as(Byte)
> :
> : Or:
> :       $baz->Byte
> :
> : That would make something like this:
> :
> :       $foo->Color.red
> :
> : the same kind of thing as:
> :
> :       $foo.as(Color).red
>
> I'm thinking the ordinary method
>
>     $foo.Color
>
> implies
>
>     $foo.as(Color)
>
> meaning that we're viewing $foo through the Color filter.  If you want to
> match against a value, however, you'd have to say
>
>     $foo.Color == green
>
> or
>
>     $foo.Color ~~ green
>
> In the latter case, you can just say
>
>     $foo ~~ green
>
> as long as "green" is unambiguous.  I don't know the syntax for
> disambiguating on the green end yet.  Maybe one of
>
>     $foo ~~ Color::green
>     $foo ~~ Color.green
>     $foo ~~ Color[green]
>
> Or maybe something else.
>
> The interesting question to me is what
>
>     $ref = \$foo.as(Color);
>
> returns.

I'll suggest:

  $ref = \$foo.as(Color);

be the same as:

  $ref = \$foo;
  $ref but= of Color; # C<of> affects type assumptions, doesn't merely add
stuff.

So that $ref is typechecked as a Color, not as a Foo.

> It looks like a typed reference to me, but it's still
> a reference to the object in $foo, or can behave as one somehow.
> I don't think it should generate a reference to the bare role, because
> roles aren't intended to be first class objects (though you can force
> them to be, I think).  Roles are supposed to encapsulate abstractions
> without implying objecthood.  I think roles are a little bit like
> quarks--they're fine in theory, but it's scary to have loose ones
> floating around.
>
> So it seems to me that $foo.Color has to return some kind of typed ref
> to $foo, so that things like
>
>     $foo.Color = purple;
>
> can work as expected.  Staring at that, it seems apparent that .Color
> is simply an lvalue subroutine just like any other rw attribute.  An
> lvalue sub can be thought of as a typed reference, I suppose.  It gets
> more interesting if the role has multiple attributes though.  What
> would
>
>     \$foo.RGB
>
> return, I wonder, such that
>
>     $foo.RGB = ($r,$g,$b)
>
> would work?
>
> Larry