Re: Comparing Object Identity
On Fri, Dec 13, 2002 at 09:32:02AM -0800, Michael Lazzaro wrote: $obj.ID; $obj.IDENTITY; FWIW, I favor the latter. --Dks
Re: Comparing Object Identity
Dave Storrs [EMAIL PROTECTED] writes: On Fri, Dec 13, 2002 at 09:32:02AM -0800, Michael Lazzaro wrote: $obj.ID; $obj.IDENTITY; FWIW, I favor the latter. I found myself mulling over: $obj.is($other_obj); Which seems to work reasonably well, and I'd be rather surprised if it clashed with anything with different semantics...
Re: Comparing Object Identity
Aaron Crane [EMAIL PROTECTED] writes:
Piers Cawley writes:
I found myself mulling over:
$obj.is($other_obj);
Which seems to work reasonably well, and I'd be rather surprised if it
clashed with anything with different semantics...
I quite like it. It also has the advantage of disallowing the equivalent
of:
my $stored_identity = $obj.id;
# Time passes...
if ($other_obj.id == $stored_identity) {
# Massive breakage ahoy
}
Ah, sorry, I thought that went without saying. So I didn't say
it. That's actually the problem that led me to come up with .is in
the first place.
There just isn't any way you can get .is() to compare identities at
different times.
Indeed. I'm definitely liking it the more I think about it. Someone
will be along to say 'but I use Cis in *all* my classes!' soon,
mark my words.
Re: Comparing Object Identity
Dave Whipp [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote : I found myself mulling over: $obj.is($other_obj); Which seems to work reasonably well, and I'd be rather surprised if it clashed with anything with different semantics... My only problem with it is the lack of symmetry. Is there any reason why an adverb syntax can't work: $a eq : ID $b # yes, I would want to generalize that I started off thinking 'well, you could just define an 'is' operator' and then realised we already have one. Hmm. Personally i don't have a problem with not having an operator for this particular functionality, I reckon it 'belongs' as a message...
Re: Comparing Object Identity
--- Dave Whipp [EMAIL PROTECTED] wrote: I can imagine writing: $a eq:i $b # compare, case insensitive $a eq:w $b # compare, ignore whitespace differences $a eq:ID $b # compare identities I think that the modifier concept is too useful to be limited to the rx// operator. But there is the issue of passing parameters to modifiers. I could live with a restriction that forces me to use the prefix (cf infix) form of the modified operator. Woo-hoo! Adverbs! This is cool. Going one step farther, $a eq:$funcptr $b or $a eq:numerically $b $a eq:soundex $b $a eq:case_insensitive So that an overridden eq could check itself (?) for properties... =Austin
Re: Comparing Object Identity
At 9:55 PM -0500 12/12/02, James Mastros wrote:
On 12/12/2002 5:24 PM, Dan Sugalski wrote:
At 2:17 PM -0800 12/12/02, Michael Lazzaro wrote:
On Thursday, December 12, 2002, at 01:41 PM, Dave Whipp wrote:
I might want to write code such as:
$remembered_id = $obj.id;
... [ time passes ] ...
if $an_object.id == $remembered_id { ... }
I think if you do this, you're probably in a world of hurt. We'd
have to assure that no object id's are *ever* reused -- so mem
addresses are out, since the same address may be used for
different things at different points in time.
There'll definitely be memory address reuse. If .id returns the
current object's memory address, it shouldn't be cached any place,
as otherwise you'll find things going bang with some regularity.
And I'd say (but who asked me -- IMHO, of course) that it should be
perfectly valid to write code like the above.
As long as valid!=correct, sure.
(That IDs should be unique across a process over all time.) If
that'd require that an object's ID be a combination of the header
address and a generation counter, that's OK. It means a
serilization point in the allocator, but I think we'd need one no
matter what (Dan?).
That's going to be expensive, and that's a bad idea. If you want an
expensive and long-lived variable tracking facility, build one and
add it on later. The base version should be fast, and sufficient for
the common case.
--
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 refere nces (Decision, Please?)) [x-adr][x-bayes]
Date: Thu, 12 Dec 2002 17:07:21 -0800 From: Larry Wall [EMAIL PROTECTED] It's not clear what .can should return for a multimethod, either. You'd have be able to return results like: yes int can mult, but only if the second argument is an int or num. Basically, .can has a bad syntax. We need a modifier on an ordinary multimethod or subroutine call that says, Go through all the motions of calling this, but don't really. To do that kind of almost-dispatch you often need the actual arguments, or something resembling them. One is tempted to say that taking a reference to a function call with arguments does something like this: \Main::foo(1,3) The reference could be bound to the dispatch list, or be false if nothing matched. Perhaps currying could be our aide: can(foo.assuming(1, 3)); The only question is, what happens when not all the arguments are curried? Perhaps it could return true if the rest of the arguments matched any multimethod. So: can(bar); Without any currying would be true if bar is a sub, and false if it isn't. I think that generalizes nicely. Luke
Re: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
Date: Thu, 12 Dec 2002 16:26:28 -0500
From: John Siracusa [EMAIL PROTECTED]
On 12/12/02 4:01 PM, Larry Wall wrote:
On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote:
: So we'll _have_ to write $obj.*id when we mean $obj-UNIVERSAL::id;
If you wish to be precise, yes. But $a.id eq $b.id should work for most any
class that uses the the term id in the typical fashion.
I still feel like we're talking past each other here. What I was saying is
that, regardless of any admonitions to the contrary, I think people will
still write this:
$a.id == $b.id
and expect it to compare memory addresses.
And presumably, anyone who overrides .id in their own class knows what
they're doing. They, in fact, Iwant statements like that to behave
that way. Junction, by delegation, will override that method to
return a junction of the .ids of its states.
Speaking of which, how do you code delegation?
class Disjunction is Junction {
has @.states is public;
# ...
# Use the class's AUTOLOAD?
method AUTOLOAD($name, *@args) {
any(map { $_.$name.(*@args) } @.states);
}
# Or use some kind of DELEGATE method, taking a curried
# function with only the invocant left blank.
method DELEGATE(func) {
any(map { $_.func } @.states);
}
}
I rather like the latter.
Luke
Re: Comparing Object Identity [x-adr][x-bayes]
On 12/13/02 10:49 AM, Garrett Goebel wrote: John Siracusa wrote: Using the method/attribute named id for this is the same object comparisons is just plain bad Huffman coding. The this is the same object method/attribute should have a name that reflects the relative rarity of its use. Other common names for the proposed .id are: UUID: Universal Unique Identifier (DCE) http://www.opengroup.org/onlinepubs/9629399/apdxa.htm GUID: Globally Unique Identfier (EFI) http://ulita.ms.mff.cuni.cz/pub/techdoc/ia64/EFISpec_092.pdf (page 319) Of the 2, usage of GUID seems to be more common IMHO. Both of the above are identical in implementation. And won't rollover until 3400AD ;) ...and if we also (or instead) want to have a universal method for getting Perl 5-style memory address hashes (FOO(0x12345)), then that should have a name without the phrase or idea of identifier anywhere in it, IMO: memhash, memaddr, etc. -John
Re: Comparing Object Identity
On Friday, December 13, 2002, at 06:56 AM, John Siracusa wrote: I'm saying that there are many kinds of objects that naturally want to have an id method or attribute that has nothing whatsoever to do with this is the same object comparisons. But if id is chosen as the name of the global this is the same object method in Perl 6, then no one can safely use a method named id (overridden or otherwise) for anything but this is the same object comparisons. I agree 100%. I use .id *often* in my coding. Or more accurately, I must connect regularly with database tables that have 'id' as a field I need to extract. :-( (And postgresql uses 'oid' as a globally unique id.) I think this is one (rare) case where an UPPERCASE or unusual name might not be a bad idea, so it will BRING ATTENTION to the fact that you're using a unusual method. $obj.ID; $obj.IDENTITY; If don't think we'll have much of a chance at teaching people to _always_ use ($obj.*id == $obj.*id) instead of ($obj.id == $obj.id). MikeL
Re: Comparing Object Identity
On Thursday, December 12, 2002, at 06:55 PM, James Mastros wrote: And I'd say (but who asked me -- IMHO, of course) that it should be perfectly valid to write code like the above. (That IDs should be unique across a process over all time.) If that'd require that an object's ID be a combination of the header address and a generation counter, that's OK. It means a serilization point in the allocator, but I think we'd need one no matter what (Dan?). I'm more worried about storing them than creating them. The good thing about using memaddresses is that they're free; you don't need to store a separate ID in each and every object you ever create, on the off chance that something will want to use it. Having an actual internal ID associated with every object would mean you'd have to store all those IDs, which could get very big very fast. I think the odds of you wanting a truly unique ID for any given class are so low that we'd probably be better off leaving it as a DIY project. MikeL
RE: Comparing Object Identity
Michael Lazzaro:
# On Thursday, December 12, 2002, at 06:55 PM, James Mastros wrote:
# And I'd say (but who asked me -- IMHO, of course) that it should be
# perfectly valid to write code like the above. (That IDs should be
# unique across a process over all time.) If that'd require that an
# object's ID be a combination of the header address and a generation
# counter, that's OK. It means a serilization point in the
# allocator,
# but I think we'd need one no matter what (Dan?).
#
# I'm more worried about storing them than creating them. The
# good thing
# about using memaddresses is that they're free; you don't need
# to store
# a separate ID in each and every object you ever create, on the off
# chance that something will want to use it.
Generating the Ids on request (i.e. the first time you call .id) would
help, but it would still mean having a slot for the information.
Honestly, I think a unique-across-the-object's-lifetime ID is probably
fine for many purposes. Perhaps we could have a sort of weak reference
that would null itself out when its referent was destroyed, if this is a
problem. (Don't know how that would work with the whole immutable hash
keys thing, though...)
--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
On 12/13/02 12:44 PM, Michael Lazzaro wrote: On Thursday, December 12, 2002, at 06:55 PM, James Mastros wrote: And I'd say (but who asked me -- IMHO, of course) that it should be perfectly valid to write code like the above. (That IDs should be unique across a process over all time.) If that'd require that an object's ID be a combination of the header address and a generation counter, that's OK. It means a serilization point in the allocator, but I think we'd need one no matter what (Dan?). I'm more worried about storing them than creating them. The good thing about using memaddresses is that they're free; you don't need to store a separate ID in each and every object you ever create, on the off chance that something will want to use it. Having an actual internal ID associated with every object would mean you'd have to store all those IDs, which could get very big very fast. You could always just autovivify them. Since most objects will never have their UUIDs accessed, the overhead should be very small. I think the odds of you wanting a truly unique ID for any given class are so low that we'd probably be better off leaving it as a DIY project. I think it's important enough to be in the core, if only to prevent fragmentation in the world of object persistence. -John
Re: Comparing Object Identity
On Fri, Dec 13, 2002 at 09:56:15AM -0500, John Siracusa wrote: Using the method/attribute named id for this is the same object comparisons is just plain bad Huffman coding. The this is the same object method/attribute should have a name that reflects the relative rarity of its use. FWIW, I have agreed with John throughout this entire thread, but I felt that he was stating things quite clearly and I didn't have anything further to add. I just want to chime in so he doesn't feel like a lone voice in the wilderness. --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 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
Luke Palmer [EMAIL PROTECTED] writes: 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. Right now there are 'sufficiently few' Object methods, but I'm betting that before the game is over there's going to a be a whole pile more, just take a look at any Smalltalk image if you don't believe me. But that's no reason for upcasing said methodnames. Anyway, you haven't lived 'til you've added a suite of methods to UNIVERSAL/Object; it's how we make Pixie work for instance. -- Piers It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite. -- Jane Austen?
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
On Thursday, December 12, 2002, at 10:49 am, Piers Cawley wrote:
Luke Palmer [EMAIL PROTECTED] writes:
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.
Right now there are 'sufficiently few' Object methods, but I'm betting
that before the game is over there's going to a be a whole pile
more, just take a look at any Smalltalk image if you don't believe
me. But that's no reason for upcasing said methodnames. Anyway, you
haven't lived 'til you've added a suite of methods to
UNIVERSAL/Object; it's how we make Pixie work for instance.
But in fairness we do distinguish our method names with a different
convention 'px_'. We prefix the methods more because people aren't
used to the UNIVERSAL::* hierarchy being mucked around in, and methods
suddenly cropping up may be surprising.
I think there may be a cultural issue here - in Smalltalk if someone
messes with a method higher up in the hierarchy its visible quickly by
virtue of the browser and the image. Adding a method in Smalltalk's
MetaObject/Class/Object hierarchy isn't going to be that dangerous,
because everybody can see that it has been added, and its therefore
culturally exposed and therefore subject to debate[0]. Not so in Perl.
Perl, of course, lets you stick a method that exists in any package
anywhere on the system[1]. You can add methods to UNIVERSAL from
anywhere, and this gets really complex when you start overriding
existing methods. For example, if you're not happy with UNIVERSAL::isa,
it can be replaced with a sub UNIVERSAL::isa {} pretty much
anywhere[2]. You may get a warning but its pretty easy to turn it off,
and tracking it down would be a real pain without some pretty serious
reflection capabilities.
Of course pretty serious reflection capabilities would be Very Nice
Indeed, but anyway...
--james.
[0] Read: argument.
[1] This is not a bad thing, its just a different thing.
[2] This probably is a bad thing in most circumstances.
RE: Comparing Object Identity
Piers Cawley:
# Luke Palmer [EMAIL PROTECTED] writes:
# Theoretically, there are sufficiently few Object methods to warrant
# normal names.
#
# Right now there are 'sufficiently few' Object methods, but
# I'm betting that before the game is over there's going to a
# be a whole pile more, just take a look at any Smalltalk image
# if you don't believe me. But that's no reason for upcasing
I'll probably burn in Hell for saying this, but in .NET System.Object
only has four methods. (One of those, however, is GetType(), which you
use to do things like UNIVERSAL::isa() in Perl.)
--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?))
(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 refere nces (Decision, Please?)) [x-adr][x-bayes]
John Siracusa wrote:
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
yes...
So we'll _have_ to write $obj.*id when we mean $obj-UNIVERSAL::id;
I'm not sure I understand what Larry means by most-global... Do you mean
outer-most scope, root-of-method-inheritence, or both?
And what of the case we someone does want to explicitly override a builtin
method like UNIVERSAL::can? What is the Perl6 equivalent to:
*UNIVERSAL::can = sub { print qq{hello\n} };
sub foo {};
print main-can('foo');
And what will:
main.*can('foo')
result in?
Larry Wall wrote:
I'd almost be tempted to argue that if push comes to shove, it's
the list splat star that gets shoved.
Don't you suspect the list splat will be more common than most-global?
Re: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote:
: John Siracusa wrote:
: 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
:
: yes...
:
: So we'll _have_ to write $obj.*id when we mean $obj-UNIVERSAL::id;
If you wish to be precise, yes. But $a.id eq $b.id should work for most any
class that uses the the term id in the typical fashion.
: I'm not sure I understand what Larry means by most-global... Do you mean
: outer-most scope, root-of-method-inheritence, or both?
It's context dependent, just as the meaning of an identifier is context dependent.
In this case, it means root-of-method-inheritance, that is, Object. (That is
tne new name of UNIVERSAL.) So $a.*id is short for $a.Object::id. But $*foo
is short for $Global::foo or some such.
: And what of the case we someone does want to explicitly override a builtin
: method like UNIVERSAL::can? What is the Perl6 equivalent to:
:
: *UNIVERSAL::can = sub { print qq{hello\n} };
: sub foo {};
: print main-can('foo');
Any of:
method Object::can ($meth) { print qq[hello\n] }
or
*can := method ($meth) { print qq[hello\n] };
or
Object::can ::= sub ($object, $method) { print qq[hello\n] };
Hmm. Those don't really stand out enough. Maybe we should go with
OBJECT:: and GLOBAL:: just for a little more visual punch.
: And what will:
:
: main.*can('foo')
:
: result in?
These days it's Main, not main. And it's a module, not a class,
so probably it fails, unless someone can think of something useful
for it to mean.
: Larry Wall wrote:
:
: I'd almost be tempted to argue that if push comes to shove, it's
: the list splat star that gets shoved.
:
: Don't you suspect the list splat will be more common than most-global?
That's why I said almost.
Larry
Re: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
On 12/12/02 4:01 PM, Larry Wall wrote: On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote: : So we'll _have_ to write $obj.*id when we mean $obj-UNIVERSAL::id; If you wish to be precise, yes. But $a.id eq $b.id should work for most any class that uses the the term id in the typical fashion. I still feel like we're talking past each other here. What I was saying is that, regardless of any admonitions to the contrary, I think people will still write this: $a.id == $b.id and expect it to compare memory addresses. That is not the typical fashion for an object method named id to work, IMO. The need to compare memory addresses is so infrequent that warrants a much less common and/or longer method name than id. -John
RE: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
Larry Wall:
# Hmm. Those don't really stand out enough. Maybe we should go with
# OBJECT:: and GLOBAL:: just for a little more visual punch.
How about CORE:: instead of GLOBAL::? This helps stick with tradition
and minimize the number of reserved packages.
# : And what will:
# :
# : main.*can('foo')
# :
# : result in?
#
# These days it's Main, not main. And it's a module, not a
# class, so probably it fails, unless someone can think of
# something useful for it to mean.
I'd hope that Perl would allow me to do something like that to see if
Main::foo exists...
--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
On 12/12/02 4:41 PM, Dave Whipp wrote: John Siracusa [EMAIL PROTECTED] wrote: memory addresses is so infrequent that warrants a much less common and/or longer method name than id. Another reason for not making these synonymous: [...] If memory addresses can change over time, then we need a more fundamental concept to act as the ID! Heh, it seems like you're supporting my position, but you're really not :) Whatever the this is the same object value actually is, I don't think it deserves to live under the method name id. -John
RE: Comparing Object Identity
Dave Whipp:
# Is the address of an object constant? Or might it be
# remapped during the life of an object. For example,
# arrays might move when they grow too big; distributed
# objects may move as they transfer onto different hosts;
# a persistent object might have a new address when
# retrieved from backing-store).
Under all systems I can think of, the memory address of an object's
header is constant. The data may move, but the header stays constant.
This is to minimize the insanity of pointer chasing in C.
--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
Brent Dax [EMAIL PROTECTED] wrote in message 00f901c2a22a$50417b30$6501a8c0@deepblue">news:00f901c2a22a$50417b30$6501a8c0@deepblue... Under all systems I can think of, the memory address of an object's header is constant. The data may move, but the header stays constant. This is to minimize the insanity of pointer chasing in C. The address may be constant for the life of the process: but some objects persist a bit longer. These cases can probably be covered by a C.guid method. Is this method a member of CObject, or only of CPersistantObject? Dave.
Re: Comparing Object Identity
On Thursday, December 12, 2002, at 01:41 PM, Dave Whipp wrote:
I might want to write code such as:
$remembered_id = $obj.id;
... [ time passes ] ...
if $an_object.id == $remembered_id { ... }
I think if you do this, you're probably in a world of hurt. We'd have
to assure that no object id's are *ever* reused -- so mem addresses are
out, since the same address may be used for different things at
different points in time. It would literally have to be a unique
serialnum attached to every single object in the process' lifespan.
And if it were to work correctly for persistent objs, it'd have to be
unique even among all perl invocations. Eeew!
Whatever's behind 'id' is probably a meaningless blob with only one
use: to determine if two vars, $obj1 and $obj2, are in fact bound to
the same thing. You can't (meaningfully) store them for use elsewhere.
Anything else seems to imply icky overhead, yes?
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
At 2:17 PM -0800 12/12/02, Michael Lazzaro wrote:
On Thursday, December 12, 2002, at 01:41 PM, Dave Whipp wrote:
I might want to write code such as:
$remembered_id = $obj.id;
... [ time passes ] ...
if $an_object.id == $remembered_id { ... }
I think if you do this, you're probably in a world of hurt. We'd
have to assure that no object id's are *ever* reused -- so mem
addresses are out, since the same address may be used for different
things at different points in time.
There'll definitely be memory address reuse. If .id returns the
current object's memory address, it shouldn't be cached any place, as
otherwise you'll find things going bang with some regularity.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Comparing Object Identity
Dan Sugalski [EMAIL PROTECTED] wrote in message news:a05200f00ba1ebb73c6d2@[63.120.19.221]... There'll definitely be memory address reuse. If .id returns the current object's memory address, it shouldn't be cached any place, as otherwise you'll find things going bang with some regularity. In a multi-threaded environment, even a simple $a.id == $b.id may have significant time between the two lookups. If we are going to rely on addresses for id comparison, then we need to mandate that the address is constant for the life of the object. Brent indicated that he could think of no reason for the header address to change: but that isn't strong enough. We need a cast- iron guarantee. Otherwise we can't compare identity using .id. Dave.
Re: Comparing Object Identity
At 2:42 PM -0800 12/12/02, Dave Whipp wrote: Dan Sugalski [EMAIL PROTECTED] wrote in message news:a05200f00ba1ebb73c6d2@[63.120.19.221]... There'll definitely be memory address reuse. If .id returns the current object's memory address, it shouldn't be cached any place, as otherwise you'll find things going bang with some regularity. In a multi-threaded environment, even a simple $a.id == $b.id may have significant time between the two lookups. No, that's not a problem, since neither $a nor $b can possibly go anywhere, as they're both being referenced. The GC is aggressive, but we do wait until a variable is at least dead before reaping 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 refere nces (Decision, Please?)) [x-adr][x-bayes]
On Thu, Dec 12, 2002 at 01:50:37PM -0800, Brent Dax wrote:
: Larry Wall:
: # Hmm. Those don't really stand out enough. Maybe we should go with
: # OBJECT:: and GLOBAL:: just for a little more visual punch.
:
: How about CORE:: instead of GLOBAL::? This helps stick with tradition
: and minimize the number of reserved packages.
I don't like the Perl 5 tradition on top-level namespaces.
First of all, nobody really knows what core means anymore. Is it
just the built-in opcodes? Is it the functions that come with the
distribution? Neither of those map onto Perl 5 concept of CORE::
anymore. So Perl 6 doesn't have a CORE:: anymore. What used to
be in CORE goes into *, whever that means.
Second, in Perl 5 there are two global namespaces apart from CORE::.
If you say $::foo, you get $main::foo. If you say $STDIN, you
get some other namespace that has no name in Perl 5. In Perl 6,
the latter truly global namespace is combined with CORE to get what
main was trying to be in Perl 5. The former main namespace is
no longer intended to be used for globals, and the $::foo syntax is
no longer supported for that purpose. The translator will translate
$::foo to $Main::foo.
So $*IN really is considered to be in the global namespace, not
in the core namespace. You might argue that stdin is core in
some sense, but all global names go into *, not just built-ins.
This includes all user-defined package names. So the real name of
package Foo is GLOBAL::Foo. It's not Main::Foo, nor is it CORE::Foo.
It's short name isn't ::Foo, but *Foo. And you can just call it Foo
because the search for identifiers ends in GLOBAL (except for methods,
for which the search ends in OBJECT).
: # : And what will:
: # :
: # : main.*can('foo')
: # :
: # : result in?
: #
: # These days it's Main, not main. And it's a module, not a
: # class, so probably it fails, unless someone can think of
: # something useful for it to mean.
:
: I'd hope that Perl would allow me to do something like that to see if
: Main::foo exists...
Ordinarily you'd test for subs with one of
exists Main::foo
Main::foo.exists
As to whether .can should work for that, it should depend on whether
it's possible to invoke foo as a method in Main. This may or may
not be the same thing as having a sub declaration named foo.
Certainly classes will distinguish subs from methods. It may be
that modules will too, and you'd have to write package Main to
get Perl to confuse them like Perl 5 does. But that's not decided yet.
It's not clear what .can should return for a multimethod, either.
You'd have be able to return results like: yes int can mult, but
only if the second argument is an int or num. Basically, .can
has a bad syntax. We need a modifier on an ordinary multimethod
or subroutine call that says, Go through all the motions of calling
this, but don't really. To do that kind of almost-dispatch you often
need the actual arguments, or something resembling them. One is tempted
to say that taking a reference to a function call with arguments
does something like this:
\Main::foo(1,3)
The reference could be bound to the dispatch list, or be false if nothing
matched.
Except that syntax currently means something else, and doesn't work
for method calls. Maybe it's a good place for a question mark:
Main::foo?(1,3)
$foo.bar?(3)
and maybe even
$x +? $y
It's vaguely possible this should be unified with currying if the
construct actually returns a reference with prebound arguments.
It's also possible that it's not visible enough, and we should say
splashy like:
can { Main::foo(1,3) }
can { $foo.bar(3) }
can { $a + $y }
Exactly how much can-{} should do without doing anything is left as
an exercise for the reader. What would it do with this:
can { $a + $y + snort() }
I suppose one could set up a transactional structure in which can
actually does the side effects hypothetically, with the option of
committing later. Sort of what a try block would like to be when
it grows up...
Larry
Re: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
On 12/12/2002 4:01 PM, Larry Wall wrote:
On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote:
: And what will:
:
: main.*can('foo')
:
: result in?
These days it's Main, not main. And it's a module, not a class,
so probably it fails, unless someone can think of something useful
for it to mean.
It would, logicaly, mean that the class Module has a method foo if
true -- applying can on an object tells you if the class of that object
can do somthing, and Main is an object of class Module... right?
(%Main:: is a hash, but Main (bareword) is an object, no?)
-=- James Mastros
Exists and hypotheticals (Was: Re: Comparing Object Identity)
On 12/12/2002 8:07 PM, Larry Wall wrote:
Ordinarily you'd test for subs with one of
exists Main::foo
Main::foo.exists
I thought that was now spelt exists %Main::{foo} -- that the symbol
tables were now just plain hashes? (And what's the methody syntax for
testing for hashkey existance -- %hash{key}.exists should get the key
element of hash, then run it's exists method, logicly. Is it
%hash.exists('key')?
I suppose one could set up a transactional structure in which can
actually does the side effects hypothetically, with the option of
committing later. Sort of what a try block would like to be when
it grows up...
Or hypothetical variables in a non-regex context...
-=- James Mastros
Re: Comparing Object Identity
On 12/12/2002 5:24 PM, Dan Sugalski wrote:
At 2:17 PM -0800 12/12/02, Michael Lazzaro wrote:
On Thursday, December 12, 2002, at 01:41 PM, Dave Whipp wrote:
I might want to write code such as:
$remembered_id = $obj.id;
... [ time passes ] ...
if $an_object.id == $remembered_id { ... }
I think if you do this, you're probably in a world of hurt. We'd have
to assure that no object id's are *ever* reused -- so mem addresses
are out, since the same address may be used for different things at
different points in time.
There'll definitely be memory address reuse. If .id returns the current
object's memory address, it shouldn't be cached any place, as otherwise
you'll find things going bang with some regularity.
And I'd say (but who asked me -- IMHO, of course) that it should be
perfectly valid to write code like the above. (That IDs should be
unique across a process over all time.) If that'd require that an
object's ID be a combination of the header address and a generation
counter, that's OK. It means a serilization point in the allocator, but
I think we'd need one no matter what (Dan?).
-=- James Mastros
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
On Wednesday, December 11, 2002, at 02:54 PM, Dave Whipp wrote: There's actually a fourth concept: two (different) objects represent the same value. (Actually, its the generalization of [1] and [2]). I think that is covered by C~~. As long as we can create class-specific variants of smart matching, we're fine. I don't know that I'd want to use Ceq for this. It's possible that you want stringification to do something not entirely normalized/canonical. MikeL
Re: Comparing Object Identity
[EMAIL PROTECTED] (Michael Lazzaro) writes: I think that is covered by C~~. As long as we can create class-specific variants of smart matching, we're fine. If we can't, case^Wgiven statements become very boring indeed. For reference, and purely for reference, Ruby has four object comparators: a == b # They have the same value a.equal?(b) # They are utterly the same object in memory a === b # They are equivalent (class-specific comparator and case # statement comparison operator) a =~ b # They match (class-specific comparator) -- Pretty, smart, sane:Pick two. - Ron Echeverri
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
