Newsgroups: perl.perl6.language
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.perl.org
Return-Path: <mlazz...@cognitivity.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
Date: Wed, 23 Apr 2003 11:10:56 -0700
Subject: Re: P6Objects: Hints, allegations & things left unsaid
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: "Perl6 Language" <perl6-langu...@perl.org>
To: "Austin Hastings" <Austin_Hasti...@Yahoo.com>
In-Reply-To: <ICELKKFHGNOHCNCCCBKFKEAMCEAA.Austin_Hastings@Yahoo.com>
Message-ID: <EDBA7F89-75B6-11D7-BB99-00050245244A@cognitivity.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
X-SMTPD: qpsmtpd/0.26-dev, http://develooper.com/code/qpsmtpd/
X-Spam-Check-By: one.develooper.com
X-Spam-Status: No, hits=-2.3 required=7.0 tests=CARRIAGE_RETURNS,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03,USER_AGENT_APPLEMAIL version=2.44
X-SMTPD: qpsmtpd/0.26-dev, http://develooper.com/code/qpsmtpd/
Approved: n...@nntp.perl.org
From: mlazz...@cognitivity.com (Michael Lazzaro)
References: <ICELKKFHGNOHCNCCCBKFKEAMCEAA.Austin_Hastings@Yahoo.com>
Lines: 127


A few comments...  Again, I've only commented where I think things have 
really, really been set in stone, so if I'm wrong on _anything_ I say, 
I'd like to know, because it will daisy-chain through quite a lot of 
other assertions I have.


On Tuesday, April 22, 2003, at 09:14  PM, Austin Hastings wrote:
> =head3 Pair Type
>
> There's a Pair type in some of Damian's messages. I hadn't really paid
> attention before, but the implication seems to be that (1) it's a 
> built-in;
> and (2) it may well be the default return type of a hash in list 
> context.
> Well, it surprised me, anyway. You got this, MikeL?
>
>      sub  draw_triangle ( Point|Pair $a is copy,
>                           Point|Pair $b is copy,
>                           Point|Pair $c is copy) {
>          when Pair {$_ = Point.new(.key,.value)} for $a, $b, $c;
>          ...
>      }

Yep, pretty sure that's been confirmed.  A hash is an unordered list of 
Pairs.  The Pair constructor is the C<=>> operator:

     $k, $v;     # a list of two elements
     $k => $v;   # a single Pair consisting of two elements.

Details on how pairs work in various contexts are a little fuzzy, but 
they probably can be inferred fairly easily.


> =head3 Everything is an object
>
> First, everything's an object. Or, according to Dan, nothing's an 
> object.
> The point is that object access will no longer be via an indirect ref 
> or
> whatever.
>
> Instead, object methods get invoked as $object.method. In keeping with 
> the
> philosophy, however, there's an awful lot of stuff that is being 
> described
> in object terms: File Handles, Arrays, Hashes, Various 'Magic' system 
> things
> (e.g., C<caller>), and the Perl6 parser itself. (Arrays, at minimum 
> "cannot
> be discerned from objects.")

"Everything will appear to be an object, in that you can call methods 
on it" was definitely confirmed.  Whether things like C<Str> are 
internally implemented as 'real' objects is unknown and probably 
irrelevant; they cannot be discerned from objects, and they can be 
subclassed as if they were objects.

(Except the lowercase primitives like C<str>, C<int>... you have to use 
C<Str>, C<Int>, etc. if you want to subclass them.)


> =head3 Everything has methods
>
> Everything, as far as I can tell, will support the .id method. This 
> includes
> the "small" types - int, num, str - as well as "first class" objects.

I don't think this was decided, was it?  Last I remember, there was 
disagreement over what to call it -- some people were begging for 
C<.identity>, since C<.id> is a very, very commonly used method name in 
most programming, and they don't want it to conflict.  (And other 
people didn't want it at all, because it allowed the programmer to do 
Stupid Things to themselves.)

It is true, however, that everything "appears" to have methods, even 
primitives like C<int> and C<str>, probably via magic.  So you can say:

    my str $s = 'blah';
    $s.chars;           # or whatever 'length' is called


> =head4 Explicit Conversion
>
> Explicit coercion (& conversion, for that matter) has been described as
> using the target type name as a subroutine name. Thus int() -> int, 
> Foo() ->
> Foo, etc.

Yes, but... personally, I have big namespace worries about this... that 
doing it that way (putting every possible conversion type in the normal 
'method' namespace, e.g. C<$string.int>, etc., will create much more 
polluted namespaces than if we required an explicit conversion 
"operator" such as C<$s as int> or C<$s to int>.


> =head5 Automatic Widening Coercion
>
> No one has had anything negative to say about automatic widening 
> coercions
> on inheritance-based superclasses. Noone has had anything whatsoever 
> to say
> about automatic widening coercion on mixin-/interface- based 
> superclasses.

I recall that some people do see a need for a way to explicitly 
_forbid_ widening... I believe this was what the C<dammit> operator was 
proposed to do?


> =head5 Automatic Lossy Conversion
>
> No one has commented on whether a Num/Float type can be assigned into 
> an Int
> type without harassment. In this case, I suspect the explicit C<$i =
> Int($f);> won't cause the peasants to revolt under C<use strict>.
>
> On the other hand, there's only Larry's inclination towards "keeping 
> the
> entry ramp low" to suggest that it will work when strict is not in 
> effect.

We really, really need a matrix of what can be autoconverted to what, 
and which of those may be lossy, if anyone's working on that...

MikeL