Stringification of references (Decision, Please?)
Michael Lazzaro
> Stringification of references
> Joseph F. Ryan kicked off a discussion of the stringification of
> objects and references and offered his suggestions. Joseph leans
> towards having the default stringifications of objects and references
> provide information useful to the programmer. I agree with him (so, if
> you spot any bias in the upcoming summary that'd be because I'm
> biased). Michael Lazzaro explicitly brought up the distinction between
> "stringification for output" and "stringification for debugging", and
> came down in favour of stringification for output (heck, he even
> wanted references to be invisible to stringification). Piers Cawley
> told him he was very wrong and appealed to the authority of Kent Beck
> (a Smalltalk and Java programmer, possibly not the *best* authority to
> choose). Michael then proposed a scheme involving subclasses of
> String, to provide cues for different stringifications, which John
> Siracusa thought was going rather a long way too far, coming down in
> favour of the "stringify for debugging" position. I'm not sure
> anything has actually been *decided* yet though. Tune in next week.
We still need this decided, ASAP, so that doc can be completed.
I doggishly maintain my preference for treating "stringification for
output" and "stringification for debugging" differently, but as long as
I can specify an "AS_STRING" (sp?) method for a class, and _still_ get
at a debugging version to print to other (debugging-related) strings, I
think we're all basically happy. That implies, however, that we need
at least two methods per type/class: AS_STRING, and AS_DEBUG, for lack
of better names. By default, the first calls the second.
(I also beg people to stop thinking about testing for
equality/equivalence between two objects as being related to their
stringification. You shouldn't be stringifying objects merely to test
if they're the same object -- yuck. It was an artifact of Perl5 that
we should be replacing.)
> of stringification for output (heck, he even wanted references to be
> invisible to stringification). Piers Cawley told him he was very wrong
Especially need to decide this. When last we joined our heroes:
On Fri, Dec 06, 2002, Dan Sugalski wrote:
> If an aggregate and a reference to an aggregate are going to behave
> the same, which is what Larry's indicated in the past, then
> stringifying a reference should be the same as stringifying its
> referent.
Larry wrote:
> This is a bit of an oversimplification.
<snip>
> But it's probably fair to say that $foo and @foo always behave
> identically in a scalar context.
(Which sortof _implies_ the answer to the question, but only
indirectly.)
MikeL
John Siracusa
> I doggishly maintain my preference for treating "stringification for
> output" and "stringification for debugging" differently, but as long as
> I can specify an "AS_STRING" (sp?) method for a class, and _still_ get
> at a debugging version to print to other (debugging-related) strings, I
> think we're all basically happy. That implies, however, that we need
> at least two methods per type/class: AS_STRING, and AS_DEBUG, for lack
> of better names. By default, the first calls the second.
Can we at least get something about "strings" in the name of the debug
method? "AS_STRING" is pretty clear, but "AS_DEBUG" could mean a lot of
things...and at first glance, it doesn't seem related to "AS_STRING" at all.
Maybe "AS_STRING" and "AS_STRING_DEBUG"? Too long? "DEBUG_STRING"? Are we
married to the "AS_*" thing? That naming scheme always seems "too cute" to
me...
> (I also beg people to stop thinking about testing for equality/equivalence
> between two objects as being related to their stringification. You shouldn't
> be stringifying objects merely to test if they're the same object -- yuck. It
> was an artifact of Perl5 that we should be replacing.)
So, what is the Perl 6 way to test this?
-John
Michael Lazzaro
On Wednesday, December 11, 2002, at 10:36 AM, John Siracusa wrote:
> Maybe "AS_STRING" and "AS_STRING_DEBUG"? Too long? "DEBUG_STRING"?
> Are we married to the "AS_*" thing?
Not really -- whatever works. We also had .debug, .identity, and .id
proposed, for example.
>> You shouldn't be stringifying objects merely to test if they're the
>> same object -- yuck. It was an artifact of Perl5 that we should be
>> replacing.)
> So, what is the Perl 6 way to test this?
I was hoping someone would ask that. :-) We don't _have_ a way,
AFAIK. It was discussed briefly during the operator thread, but
without decision. We know:
$obj1 == $obj2; # compares them numerically
$obj1 eq $obj2; # compares them stringically
We could override either C<==> or C<eq> of C<Object> to do it. Then we
have to ask what happens if you say:
$obj == 5;
$obj eq 'foo';
That would hopefully *not* compare the identity of $obj to either 5 or
'foo', but instead Do The Right Thing (numerify or stringify $obj). So
presumably, this is a job for multimethod variants of class-specific
C<==> or C<eq> operators. Well, sortof.
OR, you just explicitly compare the identities, e.g.
$obj1.identify == $obj2.identity; # yuck
OR, we have a third kind of comparision operator, like perhaps '==='.
$obj1 eq $obj2; # are their stringifications identical?
$obj1 == $obj2; # are their numifications identical?
$obj1 === $obj2; # are they in fact the same object?
The triple '===' being vaguely reminiscent of Unicode '≡'.
MikeL
Luke Palmer
> From: Michael Lazzaro <mlaz...@cognitivity.com>
>
> (I also beg people to stop thinking about testing for
> equality/equivalence between two objects as being related to their
> stringification. You shouldn't be stringifying objects merely to test
> if they're the same object -- yuck. It was an artifact of Perl5 that
> we should be replacing.)
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?
Luke
John Siracusa
> On Wednesday, December 11, 2002, at 10:36 AM, John Siracusa wrote:
>> Maybe "AS_STRING" and "AS_STRING_DEBUG"? Too long? "DEBUG_STRING"?
>> Are we married to the "AS_*" thing?
>
> Not really -- whatever works. We also had .debug, .identity, and .id
> proposed, for example.
I like the CAPS since it provides some semblance of naming isolation, but
I'm not sure what the convention is in Perl 6. All lowercase with no prefix
is out of the question, I think. I already have many, many Perl 5 objects
with "id" and "debug" methods, for example.
-John
Michael Lazzaro
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
Michael G Schwern
> 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 <sch...@pobox.com> http://www.pobox.com/~schwern/
Perl Quality Assurance <per...@perl.org> 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"
Dave Whipp
> 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<eq> (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.
Brent Dax
# Piers wrote:
# I doggishly maintain my preference for treating "stringification for
# output" and "stringification for debugging" differently, but
# as long as
# I can specify an "AS_STRING" (sp?) method for a class, and
# _still_ get
# at a debugging version to print to other (debugging-related)
# strings, I
# think we're all basically happy. That implies, however, that we need
# at least two methods per type/class: AS_STRING, and
# AS_DEBUG, for lack
# of better names. By default, the first calls the second.
I stick with .str and .id. If you're worried about namespace pollution,
maybe prefix:~ and prefix:id can be used instead.
--Brent Dax <bren...@cpan.org>
@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
Dan Sugalski
>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
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Buddha Buck
> "Michael Lazzaro" <mlaz...@cognitivity.com> 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.
>
>
>
John Siracusa
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
Michael Lazzaro
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 C<eq> for this. It's possible that
you want stringification to do something not entirely
normalized/canonical.
MikeL
Simon Cozens
> 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
Luke Palmer
> Date: Wed, 11 Dec 2002 19:21:35 -0500
> From: John Siracusa <sira...@mindspring.com>
> Reply-To: sira...@mindspring.com
> 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<id> 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
Luke Palmer
> Date: Thu, 12 Dec 2002 10:16:26 +1100
> From: Damian Conway <dam...@conway.org>
> X-Accept-Language: en, en-us
> X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
I rather like that. It's used for hashing by default (in absence of a
stringification or .hash (?) method), yes?
Luke
Luke Palmer
> 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" <mlaz...@cognitivity.com> 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
C<CaseInsensitiveString>s, 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<eq> (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
Dan Sugalski
Not for string key hashes, no.
Brent Dax
# > There's no need for special methods or (gods forbid) more operators.
# > Just:
# >
# > $obj1.id == $obj2.id
# >
# > That's what the universal C<id> 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
Dave Storrs
> "Michael Lazzaro" <mlaz...@cognitivity.com> 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
Piers Cawley
I like this. Gets 'round needing a million and one different equality
operators. If you find yourself using a particular form more often
than others then just write yourself an operator.
--
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?
Aaron Crane
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/
Piers Cawley
>> Mailing-List: contact perl6-lan...@perl.org; run by ezmlm
>> Date: Wed, 11 Dec 2002 19:21:35 -0500
>> From: John Siracusa <sira...@mindspring.com>
>> Reply-To: sira...@mindspring.com
>> 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<id> 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.
James Mastros
> 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<id> 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.
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
James A. Duncan
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.
John Siracusa
>> 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
Brent Dax
# Luke Palmer <fibo...@babylonia.flatirons.org> 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.)
James Mastros
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
Buddha Buck
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);
Larry Wall
: (This is a reply to a mail accidently sent to me personaly instead of
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
John Siracusa
> 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
Michael Lazzaro
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
Simon Cozens
> 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
Rafael Garcia-Suarez
> la...@wall.org (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.)