On Fri, Dec 13, 2002 at 09:32:02AM -0800, Michael Lazzaro wrote:
$obj.ID;
$obj.IDENTITY;
FWIW, I favor the latter.
--Dks
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
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
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
--- 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
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 ] ...
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
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
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.
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
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
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
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
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
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),
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
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
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
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
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,
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,
(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
(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
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:
:
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 ==
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
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
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
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
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:
# :
# :
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
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
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
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
[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
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
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
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
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
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
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
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
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
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
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
[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:
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
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
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,
49 matches
Mail list logo
