On Thu, 10 Aug 2000 13:22:46 +1000 (EST), Damian Conway wrote:
The RFC I'm writing specifies that if the subroutine being called has
a lazy context specifier on a given argument, that argument is only
evaluated when the value of the corresponding element of @_ is fetched,
stored, or eval'd.
So
At 03:38 PM 8/10/00 +1000, Damian Conway wrote:
An object that has many different -ify methods:
stringify
numify
hashify
listify
objectify (!)
Possible, but blech.
Why is that more blech?
Because it's
Why push it through a user subroutine. Might as well make it part of the
core language.
Why add another keyword non_lazy. though it isn't an antonym, eval{}
has the right meaning and effect.
I can see the utility of having the callee specify the alacrity of the
parameter. But this would put
Why push it through a user subroutine. Might as well make it part of the
core language.
Why exacerbate the core, when I one-line user sub can do it?
Why add another keyword non_lazy. though it isn't an antonym, eval{}
has the right meaning and effect.
No, "non-lazy" was just
"DC" == Damian Conway [EMAIL PROTECTED] writes:
$fooA-foo
$fooB-foo
What is a poor perl parser to do?
DC Ignore the prototype unless $fooA and $fooB are typed lexicals.
DC I.e. act just like it does now.
Hmm, would it be too nasty for perl to recognize that all foo's have the
I think, if you look in the archives and the Camel, you'll find that turns
out not to be the case.
I really don't like putting words in other people's mouths, so I'll
refrain. However, I have read comments from Larry and others in Camel
and perl5-porters that say something akin to this:
1.
=head1 TITLE
All Perl core functions should return objects
Yuck. Why not use the proposed want() and return hash-refs or slices,
when appropriate.
Hildo
At 07:55 AM 8/9/00 -0700, Nathan Wiger wrote:
It means a lot more code to write (and debug) for the things that
return these objects, and that means parts of perl will be
slower, take longer to write, and take up more space.
Point taken. I don't think internals should be ignored
I do agree that the internals shouldn't drive the language (otherwise a
crack team of Ninja would've already taken care of that Conway guy... :),
but neither can they be completely ignored.
Agreed. Which reminds me, we should call off those Ninja... :-)
Honestly, I'd rather you put
I don't think it will be a half million objects.
Let's take stat (and all the other long list returns). The underlying
implementation object could be a packed structure psuedohash. (Think
DSECT.) Then the only op would be the packed structure pseudohash
lookup. Which would be done at compile
On Wed, Aug 09, 2000 at 12:09:42PM -0600, Nathan Torkington wrote:
Dan Sugalski writes:
stat makes some sense. (local|gm)time makes some sense. The socket
functions make some sense. The message and shared memory functions make
some sense. Basically most of the 'advanced' functions make
At 12:09 PM 8/9/00 -0600, Nathan Torkington wrote:
stat, sockets, messaging, and the rest of the advanced stuff should
probably go to modules.
Yes, plus the get* functions. Do we need an RFC on this?
--
Peter Scott
Pacific Systems Design Technologies
At 12:09 PM 8/9/00 -0600, Nathan Torkington wrote:
I want the core to stay useful but not complex. If localtime returned
a hashref in scalar context, that'd be enough for me:
$now = localtime;
print $now-{MONTH};
print $now-{YEAR}; # already has 1900 added onto it :-)
Dan Sugalski writes:
Which sort of argues for localtime in a numeric scalar context to return
epoch seconds, in a string scalar context to return a time string, and in a
plain scalar context a hashref. (or mini-object, or tied thingamabob, or
whatever) Of course, we're trying to kill $!
I'm nervous about these different contexts. I thought scalar vs list
was confusion enough. Now we're talking about overloading even
further? We need to think VERY long and VERY hard about this before
thinking it's a good thing.
Well, I have, and I do.
(Though I'm no longer
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS At 01:33 PM 8/9/00 -0400, Chaim Frenkel wrote:
I don't think it will be a half million objects.
Let's take stat (and all the other long list returns). The underlying
implementation object could be a packed structure psuedohash. (Think
Johan Vromans wrote:
Be reminded that Perl++ will increment Perl, but return the _current_
value.
Heh, at least we're not
python = python + 1
--
John Porter
Nathan Torkington wrote:
Dan Sugalski writes:
Which sort of argues for localtime in a numeric scalar context to return
epoch seconds, in a string scalar context to return a time string, and in a
plain scalar context a hashref. (or mini-object, or tied thingamabob, or
whatever) Of
I'm pretty much opposed to this idea. It's pushing OO too far onto perl.
At 09:16 PM 8/9/00 +, David L. Nicol wrote:
Nathan Torkington wrote:
Dan Sugalski writes:
Which sort of argues for localtime in a numeric scalar context to return
epoch seconds, in a string scalar context to return a time string,
and in a
plain scalar context a hashref. (or
"DC" == Damian Conway [EMAIL PROTECTED] writes:
DC Urgh. If you want lazy eval, say so explicitly:
DC sub somesub (?@) {
DC my @foo = @_;
DC }
Where do you want the lazy specified on the caller or the callee?
Or should it be available to both? (and of course the opposite
DC Urgh. If you want lazy eval, say so explicitly:
DC sub somesub (?@) {
DC my @foo = @_;
DC }
Where do you want the lazy specified -- on the caller or the callee?
Or should it be available to both? (and of course the opposite
eval{}, to
An object that has many different -ify methods:
stringify
numify
hashify
listify
objectify (!)
Possible, but blech.
Why is that more blech?
Because it's "heavy".
However, if Dan assures me that objects will have
Damian Conway writes:
With extra contexts I can be surer:
my $yesterday = date() - 86400; # reasonable to expect epoch integer
my $today = "today is " . date(); # reasonable to expect date string
my $tomorrow = date()-{DoY} + 1; # reasonable to expect hash ref
(please hold,
What is:
$x = date();
going to return?
Probably the current scalar context result (i.e. a date string)
An object that has many different -ify methods:
stringify
numify
hashify
listify
objectify (!)
Possible, but blech.
How then
On Tue, 8 Aug 2000, Dan Sugalski wrote:
If you feel the need, it should be possible to let you do this, or at
least a part of it for one or three ops, with a module. I think it might
be better to wait until the plain way's in and then embellish it later.
I do believe (and please, folks,
On Tue, 8 Aug 2000, Mike Pastore wrote:
On Tue, 8 Aug 2000, Dan Sugalski wrote:
If you feel the need, it should be possible to let you do this, or at
least a part of it for one or three ops, with a module. I think it might
be better to wait until the plain way's in and then embellish it
Dan Sugalski wrote:
The number of different vtables needed to deal with this (along with
the functions in those tables) is rather formidable, and it will tend
to impact performance.
Hey! That sounds like an implementation topic... ;) (The internals
should be able to handle this if the
On Wed, 9 Aug 2000, Ken Fox wrote:
Dan Sugalski wrote:
The number of different vtables needed to deal with this (along with
the functions in those tables) is rather formidable, and it will tend
to impact performance.
Hey! That sounds like an implementation topic... ;) (The internals
29 matches
Mail list logo