Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
Simon Cozens <[EMAIL PROTECTED]> wrote: > [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. Java-like final methods in core classes ? (And even in Java, Object.hashCode(), which returns the object's memory address in its base implementation, is overridable.) And by the way, doesn't Perl 6 allow C<\$foo == \$bar> ? (I missed the beggining of the thread.)
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?))
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?))
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 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?))
(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?))
(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?))
On 12/11/02 11:41 PM, Luke Palmer wrote: >> 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. I use the "id" attribute of my database objects much more often than I compare object identities. IMO, "common" method names like "id" should be in the user's domain, to be used as is applicable to each kind of object. -John
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 C 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?))
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 C 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 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?))
Luke Palmer: # > There's no need for special methods or (gods forbid) more operators. # > Just: # > # > $obj1.id == $obj2.id # > # > That's what the universal C 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?))
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 C 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
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 Cs, 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 C (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?))
> 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 C method is *for*. I rather like that. It's used for hashing by default (in absence of a stringification or .hash (?) method), yes? Luke
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 C 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?))
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 C 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?))
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 '==='. I could also see :== or =:= as well. If we have $obj1 = $obj2; then presumably, ($obj1 == $obj2) is true (using '==' for your "value comparison" you discuss below). But ($obj1 === $obj2) is not necessarily true, becasue $obj1 could be a copy of $obj2, not an alias thereof. However, if you do $obj1 := $obj2; then not only is ($obj1 == $obj2) true, but so is ($obj1 === $obj2) So I could see = leading to == for comparison, and := leading to =:= for comparison. There's actually a fourth concept: two (different) objects represent the same value. (Actually, its the generalization of [1] and [2]). 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. If we wanted to test equivalence... I see === as OK, since (to me, at least) is is suggestive of the three-line equivalence symbol used mathematically. Of course, using Unicode, we could get away with using that symbol (which I don't know how to type...) Dave.
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
There's no need for special methods or (gods forbid) more operators. Just: $obj1.id == $obj2.id That's what the universal C method is *for*. Damian
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?))
"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]). 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. 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. 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 C (or, if you insist, a new operator that currently has no name). 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. Dave.
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
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; > > $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? -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Funny thing about weekends when you're unemployed. They don't mean quite so much 'cept you get to hang out with your workin' friends. - Primus "Spaghetti Western"
Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
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. $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. MikeL