Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-10 Thread Bart Lateur
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

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-10 Thread Dan Sugalski
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

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-10 Thread Chaim Frenkel
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

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-10 Thread Damian Conway
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

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-10 Thread Chaim Frenkel
"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

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-09 Thread Nathan Wiger
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.

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-09 Thread Hildo Biersma
=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

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-09 Thread Dan Sugalski
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

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-09 Thread Nathan Wiger
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

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-09 Thread Chaim Frenkel
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

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-09 Thread Jarkko Hietaniemi
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

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-09 Thread Peter Scott
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

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-09 Thread Dan Sugalski
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 :-)

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-09 Thread Nathan Torkington
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 $!

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-09 Thread Damian Conway
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

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-09 Thread Chaim Frenkel
"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

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-09 Thread John Porter
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

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-09 Thread David L. Nicol
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

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-09 Thread Steve Simmons
I'm pretty much opposed to this idea. It's pushing OO too far onto perl.

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-09 Thread Dan Sugalski
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

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-09 Thread Chaim Frenkel
"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

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-09 Thread Damian Conway
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

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-09 Thread Damian Conway
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

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-09 Thread Nathan Torkington
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,

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-09 Thread Damian Conway
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

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-08 Thread Mike Pastore
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,

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-08 Thread Dan Sugalski
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

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-08 Thread Ken Fox
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

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-08 Thread Mike Pastore
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