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),
Date: Thu, 12 Dec 2002 02:19:18 -0500
From: Dan Sugalski [EMAIL PROTECTED]
Since that may be either:
$foo = bar($x, $y), foo()
in which case it's in scalar context, or
$foo = bar($x, $y, foo())
in which case it's in list context (sort of)
The fun thing is that, potentially,
On Wed, Dec 11, 2002 at 12:13:49PM -0700, Luke Palmer wrote:
[Dks wrote:]
So...are we intending that types and type safety will be like 'use
strict' (optional and only on request), or will they be like sigils
(mandatory, can't be turned off)? Or, perhaps, on by default but able
to be
On Thu, Dec 12, 2002 at 10:35:47AM +1100, Damian Conway wrote:
Dave Storrs wrote:
- the ability for the programmer to set limiters (??better name??)
on the junction, which will specify how the junction should
collapse--e.g. always collapse to the lowest/highest value that hasn't
been
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
Simon Cozens [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Deborah Ariel Pickett) writes:
About this point was when my brain when a ha!. But I'm not yet
convinced that generating all possible parses is (a) of sane time
complexity, and (b) a little *too* DWIM for its own good.
As I said, I
Michael Lazzaro [EMAIL PROTECTED] writes:
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
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
Simon Cozens [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Dave Whipp) writes:
There is a difference between verbs and noun. Sometimes you don't want
to associate a verb with an object: you want to associate it with the
subject:
Verbs are almost always associated with their subject in OO
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/10/2002 5:46 PM, Smylers wrote:
OK. There was something on MJD's QOTW recently where using the current
Perl 5 Memoize module slowed code down -- that gave me the impression
that caching had the potential.
It does. In fact, all caching has that potential. Specificly, if the
time to look
[EMAIL PROTECTED] (Stephen McCamant) writes:
Simon I'm afraid I can't tell whether or not I'm being serious any
Simon more.
I don't know if this has been discussed before, but there are
completely serious parsing algorithms that work this way
Morale: If you can come up with a crazy enough
Michael Lazzaro asked:
foo $a, $b, $c, $d; # how many args?
Damian Conway wrote:
Yep. Can't be known unless predeclared and hence compile-time discernible.
And methods can't be discerned in the presence of run-time dispatch.
Is that not the purpose of an interface? That is, to specify at
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,
On Tue, 10 Dec 2002 13:02:18 -0800, Brent Dax wrote:
Peter Haworth:
# @b = @a.grep { /\S/ }, $c;
#
# how does the compiler know whether $c is an argument to grep,
# or another element to be assigned to @b?
The same way it does when it sees a normal sub?
I know, late binding and all
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Wed, 11 Dec 2002 17:24:54 -0800
From: Dave Storrs [EMAIL PROTECTED]
Mail-Followup-To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Content-Disposition: inline
X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
On Thu, Dec 12, 2002
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,
It seems to me that the simplest disambiguating rule is to require the
parentheses on methods.
The way I see it, any sort of matching of what [multi-]?method is to be called,
is automatically doomed to failure. But I don't think that means we need to
require parentheses, except to override the
On Thu, Dec 12, 2002 at 09:43:26AM -0600, Adam D. Lopresto wrote:
So basically we can leave off the parentheses in the usual
cases, but they're still required when you're doing something unusual
or that would otherwise be hard to read.
Which is simpler? You don't need parentheses except in
--- Dave Whipp [EMAIL PROTECTED] wrote:
We seem happy to structure objects (using
attributes, etc.), but verbs remain flat and uninteresting: just
arbitrary names.
As a result of this lack of expressiveness in the grammar, we find
ourselves saying that if a concept doesn't fit the
(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 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
universal than 'array'. And we could easily use that
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
One possibility for R-to-L pipelines that would also solve the
namespace issues associated with reserving lots of keywords like map
and grep and part would be to have a quite literal inverse-C.
grammar. So instead of saying
$a.foo(args)
you could _always_ say an equivalent
foo(args)
Date: Thu, 12 Dec 2002 10:11:00 -0800
From: Michael Lazzaro [EMAIL PROTECTED]
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,
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
Jonathan Scott Duff wrote:
On Thu, Dec 12, 2002 at 09:43:26AM -0600, Adam D. Lopresto wrote:
So basically we can leave off the parentheses in the usual cases,
but they're still required when you're doing something unusual or
that would otherwise be hard to read.
Which is simpler? You
[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
Michael Lazzaro wrote:
I would still like to be able to do things in Perl6 like:
@out = sort map {...} grep { ... } @in;# [1]
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
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 10:40:20PM -, Smylers wrote:
What if the thing being Csorted (or whatever) is not an array but a
list?
@out = sort $scalar, @array, result_of_calling_function($param);
Would the list have to be stored in an array before it could be sorted?
I would hope Perl
On Thursday, December 12, 2002, at 02:40 PM, Smylers wrote:
What if the thing being Csorted (or whatever) is not an array but a
list?
@out = sort $scalar, @array, result_of_calling_function($param);
Would the list have to be stored in an array before it could be sorted?
I hope and expect
On Wed, Dec 11, 2002 at 06:53:20PM -0800, Randal L. Schwartz wrote:
Rich == Rich Morin [EMAIL PROTECTED] writes:
Rich On occasion, I have found it useful to cobble up a little language
Rich that allows me to generate a list of items, using a wild-card or some
Rich other syntax, as:
Rich
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 Thu, Dec 12, 2002 at 04:17:44PM -0800, Michael G Schwern wrote:
: On Thu, Dec 12, 2002 at 10:40:20PM -, Smylers wrote:
: What if the thing being Csorted (or whatever) is not an array but a
: list?
:
:@out = sort $scalar, @array, result_of_calling_function($param);
:
: Would the
On Wed, Dec 11, 2002 at 06:50:12PM -0800, Michael Lazzaro wrote:
:
: On Wednesday, December 11, 2002, at 06:41 PM, Michael Lazzaro wrote:
:print $i; # ILLEGAL; use $STDOUT.print($i) or $i.print (?)
:reverse @a; # ILLEGAL; use @a.reverse;
:map {...} @a; # ILLEGAL; use
On Wed, Dec 11, 2002 at 11:36:17PM +, Simon Cozens wrote:
: [EMAIL PROTECTED] (Michael G Schwern) writes:
: If you want a tactile grasp of the Everything is an object concept, try
: some Ruby.
:
: If you want a tactile grasp of Perl 6, try some Ruby. But I'll be saying
: a lot more on that
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
On Thursday, December 12, 2002, at 01:11 PM, Michael Lazzaro wrote:
We can make that
@out = @in.grep({...}).map({...}).sort;# [2]
if we want to grind our OO axe, but I find that syntax disappointing.
I like that the idea is important enough in Perl to have it's own
grammar, but I
54 matches
Mail list logo
