--- 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.
"Piers Cawley" <[EMAIL PROTECTED]> wrote :
> > $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 par
"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
"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
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 ad
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 $sto
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 sur
On Fri, Dec 13, 2002 at 09:32:02AM -0800, Michael Lazzaro wrote:
>
> $obj.ID;
> $obj.IDENTITY;
FWIW, I favor the latter.
--Dks
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 ] ...
Michael Lazzaro wrote:
>
> I'm more worried about storing them than creating them.
> The good thing about using memaddresses is that they're
> free;
An UUID could be free up until the point where you request it.
> I think the odds of you wanting a truly unique ID for any
> given class are so l
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
>
> 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 w
Michael Lazzaro wrote:
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
_alwa
On Fri, Dec 13, 2002 at 09:49:44AM -0600, Garrett Goebel wrote:
> Other common names for the proposed .id are:
>
> UUID: Universal Unique Identifier (DCE)
> GUID: Globally Unique Identfier (EFI)
>
> Of the 2, usage of "GUID" seems to be more common IMHO. Both of the above
> are identical in imple
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.
On Thu, Dec 12, 2002 at 09:39:18PM -0500, James Mastros wrote:
> 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
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.)
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 a
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 combinat
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 globa
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
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.
[...]
> Using the method/attribute named "id" for "this is
> the same object" compari
On 12/13/02 5:09 AM, Luke Palmer wrote:
>> 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 preci
> 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 prec
> 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 syn
Simon Cozens <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Larry Wall) writes:
> > Which basically comes down to this: an id represents a location in
> > memory for any objects that don't override the .id method.
>
> Aiee! No! Please don't let things override the address-in-memory method,
> as
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 t
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 exista
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 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
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
"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.
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
[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 b
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 obje
--- Brent Dax <[EMAIL PROTECTED]> wrote:
> 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 persist
"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 minim
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
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 tim
"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:
Is the address of an object constant? Or might it be
remapped during the life of an object. For ex
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.*c
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 t
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 requi
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
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
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
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:
:
(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 diff
(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-on
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,
On 12/11/02 11:41 PM, Luke Palmer wrote:
>> More generally, I really don't want to have too many (any?) "system" object
>> method names squatting in "my" all-lowercase object method namespace. It's
>> not hard to think of many kinds of objects that would naturally have an "id"
>> attribute, but mu
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:
On 12/12/2002 5:50 AM, Aaron Crane wrote:
Damian Conway writes:
There's no need for special methods or (gods forbid) more operators.
Just:
$obj1.id == $obj2.id
That's what the universal C method is *for*.
How universal are universal methods?
That is, can a programmer override .id() in a
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
Damian Conway writes:
> There's no need for special methods or (gods forbid) more operators.
> Just:
>
> $obj1.id == $obj2.id
>
> That's what the universal C method is *for*.
How universal are universal methods?
That is, can a programmer override .id() in a user-defined class? If so,
simpl
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
Luke Palmer:
# > There's no need for special methods or (gods forbid) more operators.
# > Just:
# >
# > $obj1.id == $obj2.id
# >
# > That's what the universal C method is *for*.
#
# I rather like that. It's used for hashing by default (in
# absence of a stringification or .hash (?) method
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
> 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 Micro
> 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 m
> 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
[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 comparato
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
On 12/11/02 6:16 PM, Damian Conway wrote:
> There's no need for special methods or (gods forbid) more operators.
> Just:
>
>$obj1.id == $obj2.id
>
> That's what the universal C method is *for*.
I must have missed this (or forgotten it?) Any chance of it becoming .ID or
.oid or even ._id? I
Dave Whipp wrote:
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote:
After thinking about it a little more, I'll set myself on the "yes"
side. And propose either '===' or ':=:' to do it.
Definitely '==='.
I could also see :== or =:= as well.
If we have
$obj1 = $obj2;
then presumably, ($obj1
There's no need for special methods or (gods forbid) more operators.
Just:
$obj1.id == $obj2.id
That's what the universal C method is *for*.
Damian
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
"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?
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 differen
68 matches
Mail list logo
