RE: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
Luke Palmer:
# There's no need for special methods or (gods forbid) more operators.
# Just:
#
# $obj1.id == $obj2.id
#
# That's what the universal Cid method is *for*.
#
# I rather like that. It's used for hashing by default (in
# absence of a stringification or .hash (?) method), yes?
I'd assume so, but more by default rather than by design:
class Object {
method hash() {
return .str();
}
method str() {
return .id();
}
method id() {
return sprintf(%s(%#x), .class,
Perl6::addressof($_));
#Or some such nonsense
}
}
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible.
--Ayn Rand, explaining how today's philosophies came to be
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
On Wed, Dec 11, 2002 at 02:54:18PM -0800, Dave Whipp wrote: Michael Lazzaro [EMAIL PROTECTED] wrote: After thinking about it a little more, I'll set myself on the yes side. And propose either '===' or ':=:' to do it. Definitely '==='. Hopefully, this thread has been settled by Damian's pointing out the existence of id(), but could I put in a strong vote against the use of '===' for anything? It is far too easy to misread as ==, IMHO. --Dks
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
Damian Conway writes: There's no need for special methods or (gods forbid) more operators. Just: $obj1.id == $obj2.id That's what the universal Cid method is *for*. How universal are universal methods? That is, can a programmer override .id() in a user-defined class? If so, simply comparing .id for numeric equality isn't a good enough way of comparing object identity. I think you'd have to do something like $obj1.UNIVERSAL::id == $obj2.UNIVERSAL::id which is getting fairly verbose. But I also have a feeling of non-specific unease at the idea that I might _not_ be able to override a universal method. Another question. Consider the integer 17. There are two plausible representations for it -- one boxed, and one unboxed. There might also be several distinct boxed 17s that aren't object-identical. My question is whether all of those should have the same .id(). That is, should the programmer be allowed to determine whether two apparently-identical numbers have the same representation, or should .id() fudge the issue by pretending that all representations of a number of a given type are identical. -- Aaron Crane * GBdirect Ltd. http://training.gbdirect.co.uk/courses/perl/
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
On 12/12/2002 5:50 AM, Aaron Crane wrote: Damian Conway writes: There's no need for special methods or (gods forbid) more operators. Just: $obj1.id == $obj2.id That's what the universal Cid method is *for*. How universal are universal methods? That is, can a programmer override .id() in a user-defined class? If so, simply comparing .id for numeric equality isn't a good enough way of comparing object identity. I'd say that you can override .id, but if you do, you deserve what you get. That is to say, if your .id method lies, and somebody tests that two objects are the same with .id, you should be sure that you're prepared to accept all the complications of answering the way you do. Also, it's likely that .id will be implemented with a single Parrot opcode, so you'll loose a lot of efficency by overriding it. Another question. Consider the integer 17. There are two plausible representations for it -- one boxed, and one unboxed. There might also be several distinct boxed 17s that aren't object-identical. My question is whether all of those should have the same .id(). 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. Thus, there should be one ID for all constants of the same value, which is different from all constants of different value. (This is probably unimplementable if we gaurntee IDs are of some constant length.) Two objects should only have the same ID if they are aliases of each-other: they always have the same instance values, and the same value (but) properties. Promotable, but unpromoted, Ints should have different IDs, because they may at some point, have different values. Any unconsidered cases? That is, should the programmer be allowed to determine whether two apparently-identical numbers have the same representation, or should .id() fudge the issue by pretending that all representations of a number of a given type are identical. Some of both. Not all constants of the same number neccessarly have the same reprensentation in PBC -- to whit, a constant float in different compilation units will get different slots in the constant table, but are really identical. The same is true of constant strings. (Constant integers are inlined, and thus this doesn't apply to them -- they really are identical.) -=- James Mastros
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
(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. -=- James Mastros
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
(resent as requested)
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.
Thus, there should be one ID for all constants of the same value, which
is different from all constants of different value. (This is probably
unimplementable if we gaurntee IDs are of some constant length.)
Two objects should only have the same ID if they are aliases of
each-other: they always have the same instance values, and the same
value (but) properties.
Promotable, but unpromoted, Ints should have different IDs, because they
may at some point, have different values.
Any unconsidered cases?
What about value objects (objects with no methods to change state after
creation?
class Complex {
# Hmmm, what's the attribute syntax this week?
attr .real is ro is public;
attr .imaginary is ro is public;
sub new($r, $i) {
my Complex $obj;
$obj.real = $r;
$obj.imaginary = $i;
return $obj;
}
method .magnitude { return sqrt($.real * $.real
+ $.imaginary * $.imaginary);
}
method .conjugate ( return Complex::new($.real, -$.imaginary); }
sub operator::* (Complex $a, Complex $b) is exported {
return Complex::new($a.real*$b.real-$a.imaginary*$b.imaginary,
$a.real*$b.imaginary+$a.imaginary*$b.real);
}
}
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:
my Complex $a = Complex::new(5,4);
my Complex $b = Complex::new(5,4);
Is it reasonable to have $a.id == $b.id?
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
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
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
On 12/12/02 12:55 PM, Larry Wall wrote: 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(). That'll only work out if everyone always writes it as *id. If not, my Perl 6 objects that override id() won't work correctly with any other classes or functions that simply call id and expect it to really be *id But I suspect the reverse will happen. Everyone will just expect $a.id to be functionally the same as $a.*id, so no one will actually ever write $a.*id. And so I'm back to losing the ability to have id attributes on objects in Perl 6 that represent anything other than a place in memory, and back to my complaint about a system method hogging a common (IME) and sensible method name for many kinds of objects, using it to store information that is very infrequently accessed. Is one extra letter going to kill anyone? .uid? .oid? C'mon, throw me a bone here... :-} -John
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
On Wednesday, December 11, 2002, at 06:48 PM, Dave Storrs wrote: Hopefully, this thread has been settled by Damian's pointing out the existence of id(), but could I put in a strong vote against the use of '===' for anything? It is far too easy to misread as ==, IMHO. Yes, I think it's settled, minus some arguing over the spelling of 'id'. I proposed '===' to see what would happen. Now having seen what would happen, I withdraw it. :-) We have: $foo == $bar;# numerically equivalent $foo eq $bar;# stringically equivalent $foo ~~ $bar;# (smartmatch) equivalent $foo.id == $bar.id; # compare identity There are no others, unless you roll them yourself. But note that ~~ is broad in meaning -- for each class, you can decide that equivalence means whatever you want it to mean. MikeL
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
[EMAIL PROTECTED] (Larry Wall) writes: Which basically comes down to this: an id represents a location in memory for any objects that don't override the .id method. Aiee! No! Please don't let things override the address-in-memory method, as that makes foo.id == bar.id comparisons dubious at best and useless at worst. -- You stupid? All of Europe (maybe except those crazy Brits) prints on A4 paper. Crazy we may be, but not foolscap. -- James Kilfiger, ctt
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
At 2:28 PM -0800 12/11/02, Michael G Schwern wrote: On Wed, Dec 11, 2002 at 02:15:40PM -0800, Michael Lazzaro wrote: On Wednesday, December 11, 2002, at 11:16 AM, Luke Palmer wrote: This brings up something that's been on the tip of my toungue for awhile. In many object-oriented languages we have seen that there is an important difference between equal and same. Perl already has two kinds of equal, but IIRC there is nothing to test whether two variables refer to the same place in memory. Should there be? After thinking about it a little more, I'll set myself on the yes side. And propose either '===' or ':=:' to do it. Given that this will not be a commonly used feature, I wouldn't give it a special operator. Just use a method. $foo.sameas $bar; %foo.sameas %bar; @foo.sameas @bar; I'd have to agree. Testing for this sort of thing seems relatively uncommon, and wasting punctuation on it doesn't seem worth it. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
On 12/11/02 6:16 PM, Damian Conway wrote: There's no need for special methods or (gods forbid) more operators. Just: $obj1.id == $obj2.id That's what the universal Cid method is *for*. I must have missed this (or forgotten it?) Any chance of it becoming .ID or .oid or even ._id? I'm kind of attached to using an id method on objects that represent things in a database... :-/ More generally, I really don't want to have too many (any?) system object method names squatting in my all-lowercase object method namespace. It's not hard to think of many kinds of objects that would naturally have an id attribute, but must now have foo_id and bar_id methods because the (probably rarely used) id method from UNIVERSAL (or whatever it is today) is hogging it. (The more I think about it, the more I like some kind of reserved prefix like _ or even perl_...but I'd accept oid :) -John
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Date: Wed, 11 Dec 2002 19:21:35 -0500 From: John Siracusa [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/ On 12/11/02 6:16 PM, Damian Conway wrote: There's no need for special methods or (gods forbid) more operators. Just: $obj1.id == $obj2.id That's what the universal Cid method is *for*. I must have missed this (or forgotten it?) Any chance of it becoming .ID or .oid or even ._id? I'm kind of attached to using an id method on objects that represent things in a database... :-/ Well I use .str all the time, an .eq is one of my favorites! Don't take those, put a prefix on them! Theoretically, there are sufficiently few Object methods to warrant normal names. Also, when I write programs, I tend to design things to look as built in as possible. Once I've got a 500-line system going, I don't have to make the distinction between built in and my code, and modules' code. It's all part of the language, once I've put it there. In summary, my world view is that the language isn't there to help you code your own things; rather, you're extending the language constantly until the program can look like this: process for ; More generally, I really don't want to have too many (any?) system object method names squatting in my all-lowercase object method namespace. It's not hard to think of many kinds of objects that would naturally have an id attribute, but must now have foo_id and bar_id methods because the (probably rarely used) id method from UNIVERSAL (or whatever it is today) is hogging it. I'd argue that you'd better pick a better name than .id anyway. You wouldn't use .foo_id and .bar_id, you'd use .descriptor or .index (though that one's not too much more descriptive than .index). I'd say .id should be kept short and sweet, because it's going to be used on a wider variety of objects than your database .id. (The more I think about it, the more I like some kind of reserved prefix like _ or even perl_...but I'd accept oid :) die $human.oid; Luke
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
From: Dave Whipp [EMAIL PROTECTED]
Date: Wed, 11 Dec 2002 14:54:18 -0800
Organization: Fast-Chip inc.
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4920.2300
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300
X-Posted-By: 64.161.209.178
Michael Lazzaro [EMAIL PROTECTED] wrote:
After thinking about it a little more, I'll set myself on the yes
side. And propose either '===' or ':=:' to do it.
Definitely '==='.
This is used in various other languages.
$obj1 eq $obj2;# [1] are their stringifications identical?
$obj1 == $obj2;# [2] are their numifications identical?
$obj1 === $obj2; # [3] are they in fact the same object?
The reason being that you could in fact want to say any of [1], [2],
and [3] as separate, useful concepts. So merely overloading '==' or
'eq' would not be sufficient, as it would hide the previous, still
useful meanings.
There's actually a fourth concept: two (different) objects represent
the same value. (Actually, its the generalization of [1] and [2]).
So do 0123 and 123 represent the same value? Sometimes.
Unfortunately, this concept gets fuzzy because there may be multiple
equivalence classes that define different values of same-ness for a
given pair of objects. As a trivial example, consider the equivalence
class of case insensitivity, applied to strings. The current way of
defining this is to say:
($a.lc eq $b.lc) # assuming lc is a member, not a sub
But this requires us to create two new strings before we can
compare them. Whilst there might be optimizations for special
cases, the general problem remains: its not nice to define
equivalence classes as conversions to strings/numbers.
Another way of expressing the above example, is:
$a.compare_case_insensitive($b)
or
compare_case_insensitive($a, $b)
This is a general solution, but it seems a bit heavyweight for
many/most specific cases.
In general, there is no, um, general solution. Another equivalence
class is whether two strings are equal when you change there first
character to 'R'. cat and hat share this. But you wouldn't want
a method for it.
It seems to me that most objects/classes have a default
definition of sameness. For this, it'd be nice to use a
simple operator (e.g. '==' or 'eq') If I defined
my Str $a is CaseInsensitive = hELLO;
then I would like C $a eq Hello to DWIM.
class CaseInsensitiveString is Str;
sub operator:eq (CaseInsensitiveString $a, Str $b) {
lc $a eq lc $b
}
sub operator:eq (Str $a, CaseInsensitiveString $b) {
$b eq $a
}
(Technical detail: What would $a eq $b choose if both $a and $b are
CCaseInsensitiveStrings, as both methods are equidistant from that
expression?)
Can this be applied to other objects? If I have a class named
PostalAddress, then I'd expect to compare them as addresses,
not as strings. Instead of
$a.canonical_value eq $b.canonical_value.
I just want to use Ceq (or, if you insist, a new operator
that currently has no name).
Sure. Just overload it. That's what overloading is for.
Sameness is probably a more common operator then identical-ness
(I use the latter frequently: but I write a lot of code for testing and
debugging -- its my job). So perhaps the C=== operator could
be used for comparison under the default equivalence-class of the
operands. I'd find it unintuitive, but I'm could get used to it.
I'm in favor of just using $a.id == $b.id. But the idea of === was to
override what the object thought of as equal, and find out whether it
is precisely the same object.
Luke
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
At 9:43 PM -0700 12/11/02, Luke Palmer wrote: Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm X-Sent: 11 Dec 2002 23:16:30 GMT Date: Thu, 12 Dec 2002 10:16:26 +1100 From: Damian Conway [EMAIL PROTECTED] X-Accept-Language: en, en-us X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/ There's no need for special methods or (gods forbid) more operators. Just: $obj1.id == $obj2.id That's what the universal Cid method is *for*. I rather like that. It's used for hashing by default (in absence of a stringification or .hash (?) method), yes? Not for string key hashes, no. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
