Austin Hastings <[EMAIL PROTECTED]> writes:
> --- Piers Cawley <[EMAIL PROTECTED]> wrote:
>
> >
> > Both of your proposed options are, frankly, vile. The
> > multimethod/generic function approach has the advantage of putting
> > the 'burden' of writing the generic function on the implementor
> >
--- Piers Cawley <[EMAIL PROTECTED]> wrote:
>
> Both of your proposed options are, frankly, vile. The
> multimethod/generic function approach has the advantage of putting
> the
> 'burden' of writing the generic function on the implementor rather
> than on the user. Given that implementation happ
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 <[EMAIL PROTECTED]> writes:
> >> The only encompassing solution would seem to be to find a grammar rule
> >> by which map,grep,etc are unambiguously methods of Array, but can
> >> still be called in a fashion similar to [1]. That would, I suspect,
> >> satisfy everyone.
>
> On Fr
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
Damian Conway writes:
> Famous last words. ;-)
>
>
> > Was it ever decided what C would look like with multiple streams?
>
> for zip(@x, @y, @z) -> $x, $y, $z {...}
>
> and its operator version:
>
> for @x ¦ @y ¦ @z -> $x, $y, $z {...}
>
>
> > Maybe we could just use
The only encompassing solution would seem to be to find a grammar rule
by which map,grep,etc are unambiguously methods of Array, but can
still be called in a fashion similar to [1]. That would, I suspect,
satisfy everyone.
On Friday, December 13, 2002, at 03:07 AM, Piers Cawley wrote:
What's w
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
Michael Lazzaro <[EMAIL PROTECTED]> writes:
> On Wednesday, December 11, 2002, at 06:56 PM, Simon Cozens wrote:
> > [EMAIL PROTECTED] (Michael Lazzaro) writes:
> >> Wel... yes and no. You can make the same argument for operators
> >> upon scalars, for example, since 'scalar' is arguably no m
> 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
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Thu, 12 Dec 2002 17:33:06 -0800
> From: Larry Wall <[EMAIL PROTECTED]>
> Mail-Followup-To: [EMAIL PROTECTED]
> Content-disposition: inline
> X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
>
> On Wed, Dec 11, 2002 at 06:50:
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
23 matches
Mail list logo
