On Thu, Dec 12, 2002 at 12:20:18PM -0500, James Mastros wrote:
: (This is a reply to a mail accidently sent to me personaly instead of
: the list. Buddha, care to resend your other mail? I havn't quoted it
: in total.)
:
: On 12/12/2002 9:43 AM, Buddha Buck wrote:
:
: >James Mastros wrote:
: >
: >>Here's my basic defintion of ID: Two things should have the same ID
: >>if-and-only-if they will behave exactly the same, now and forevermore.
: >
: >If I wrote the Perl6 code correctly (and no guarantees that I hit this
: >moving target), then once created, a Complex object cannot be modified
: >and is indistinguishable by behavior from any other Complex object
: >with the same value:
: >
: >Is it reasonable to have $a.id == $b.id?
:
: No, as you can still change the properties of the objects independently.
: If you can't even do that, then yes.
Which basically comes down to this: an id represents a location in
memory for any objects that don't override the .id method. If you want
to compare two immutable values to see if they're the same value, use a
value comparison, not an id comparison! Whether two equivalent values
will happen to have the same id should be considered an implementation
detail, and should not generally be relied upon outside the class
because it breaks encapsulation, insofar as it prevents a class from
changing between shared and non-shared implementations of equivalent
values. I see nothing wrong with having multiple objects with the same
value, even if they happen to be immutable objects. It's up to the
constructor to enforce identity of equivalent immutable values, if the
class wants to do that.
As for namespace pollution and classes that use .id in Perl 5, I
don't think it's going to be a big problem. Built-in identifiers
do not have a required prefix, but they have an optional prefix,
which is C<*>. I think we can probably parse
$a.*id == $b.*id
if you really need to get to Object.id(). If our most-global splats
start interfering with our list-flattening splats, we'll have to
change one or the other. It's the concepts that are important, not
the particular character. The general concept is that standard names
should be easy to hide locally, but it should be almost as easy to
get back to the standard definition. One extra character like * is
good Huffman coding for that. Getting back to intermediate "super"
or "outer" versions doesn't have to be so easy, so we have things
like SUPER:: and OUTER:: for that.
I'd almost be tempted to argue that if push comes to shove, it's
the list splat star that gets shoved.
Larry
