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:12PM
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
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 more
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
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
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
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 Friday, December
--- 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 happens
13 matches
Mail list logo
