On Mon, Sep 18, 2000 at 01:01:55PM -0400, John Siracusa wrote:
> Don't forget the fact that direct access is much faster than a method
> call in Perl 5. This will be fixed in Perl 6, of course...right? :)
RFC 163
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
>Okay, we get the idea! Only very simple things should interpolate.
>Do you have any other objections to the RFCs?
Yes: to the mail volume. And I'm about to fix that.
On Mon, Sep 18, 2000 at 07:30:37AM -0600, Tom Christiansen wrote:
> >So what about
>
> > print "Thanks, $user->{'first name'} for your order!";
>
> >Which needs nested quotes already?
>
> printf() is more readable in such cases.
Okay, we get the idea! Only very simple things should interpol
>As Nate pointed out: print "$hash->{'f'.'oo'}" already works fine and
>the world spins on.
That is no argument for promoting illegibility.
--tom
On Mon, Sep 18, 2000 at 07:23:41AM -0600, Tom Christiansen wrote:
> >> Oh joy: now Perl has nested quotes. I *hate* nested quotes.
> >Those are single-quotes inside double-quotes.
>
> Yep: nested, with varying semantic effects. Completely nasty.
As Nate pointed out: print "$hash->{'f'.'oo'}"
On 9/18/00 3:44 AM, Damian Conway wrote:
>>> my $weather = new Schwern::Example;
>>> print "Today's weather will be $weather->{temp} degrees and sunny.";
>>> print "And tomorrow we'll be expecting ", $weather->forecast;
>>
>> You are wicked and wrong to have broken inside and peeked at the
Tom Christiansen wrote:
>
> >So what about
>
> > print "Thanks, $user->{'first name'} for your order!";
>
> >Which needs nested quotes already?
>
> printf() is more readable in such cases.
I guess we just have a difference opinion on what consitutes making
things easy.
-Nate
>So what about
> print "Thanks, $user->{'first name'} for your order!";
>Which needs nested quotes already?
printf() is more readable in such cases.
--tom
>It hurts me to do this when there's even a little bit of data, since it
>ends up spanning lines really quickly. And it's harder to read and
>figure out how everything lines up. Honestly, which is easier to read
>and code?
>print "Thanks, ", $q->param('name'), " for your order of ",
>$q->param('a
>> Oh joy: now Perl has nested quotes. I *hate* nested quotes.
>Those are single-quotes inside double-quotes.
Yep: nested, with varying semantic effects. Completely nasty.
-tom
Tom Christiansen wrote:
>
> You are wicked and wrong to have broken inside and peeked at the
> implementation and then relied upon it.
I agree completely. So Perl should make it easier to deal with class
methods.
> >I find myself wanting to say:
>
> > print "Thanks, $cgi->param('name') for y
On Mon, Sep 18, 2000 at 01:12:10AM -0600, Tom Christiansen wrote:
> You are wicked and wrong to have broken inside and peeked at the
> implementation and then relied upon it.
That's a new one for perldiag. Would that be (S) or (X)?
> > print "Thanks, $cgi->param('name') for your order!";
> >
> > my $weather = new Schwern::Example;
> > print "Today's weather will be $weather->{temp} degrees and sunny.";
> > print "And tomorrow we'll be expecting ", $weather->forecast;
>
> You are wicked and wrong to have broken inside and peeked at the
> implementation and then
>I doubt anyone's arguing that they're not function calls. What I find
>"surprising" is that Perl doesn't DWIM here. It doesn't encourage data
>encapsulation or try to make it easy:
> my $weather = new Schwern::Example;
> print "Today's weather will be $weather->{temp} degrees and sunny.";
>
Tom Christiansen wrote:
>
> Funny--I always think of them as function calls, and don't expect
> function calls to expand.
I doubt anyone's arguing that they're not function calls. What I find
"surprising" is that Perl doesn't DWIM here. It doesn't encourage data
encapsulation or try to make it e
On Sun, Sep 17, 2000 at 08:56:23PM -0600, Tom Christiansen wrote:
> While you're there, you should fix it to spell piñatas properly. :-(
> We're not talking about stands of pine trees, presumably.
Funny, I know how to type extended characters in MacOS, but I have no
idea how to do it in X. Hell,
># $inventory->pinatas returns a list of pinatas we have.
># "Yes, El Guapo, I would say I have 23 pinatas\n";
>print "Yes, El Guapo, I would say I have $inventory->pinatas pinatas\n";
>I appear to have a new version of the RFC ready without the first even
>having made it out to the p
>I think it's far more inconsistent to have the above work but not have
>methods interpolate. And yes, I realize they're different thingies but
>they're very close syntactically and cognitively,
Funny--I always think of them as function calls, and don't expect
function calls to expand.
>especia
Sorry, I wasn't subscribed to perl6-language-objects and didn't even
realize there was a discussion going on. I just fixed that.
I didn't mean to hijack RFC 103, I can't remember if I'd even looked
at it before... but Nathan seems okay with that and it is a
deceptively large issue.
Version 2 of
Tom Christiansen wrote:
>
> >print "Today's weather will be $weather->temp degrees and sunny.";
>
> So, the -> operator is supposed to get expanded in dq strings, eh?
It already does, or at least appears to to users:
print "Today's weather will be $weather->{temp} degrees and sunny.";
On Sun, Sep 17, 2000 at 07:55:43PM -0600, Tom Christiansen wrote:
> So, the -> operator is supposed to get expanded in dq strings, eh?
>
> What about class methods, like "Give him Employee->salary() again"?
Because I knew this would raise problems, "Interpolation of class
method calls" was pre
>Or DWIM "${\foo()}" to force scalar context. Everytime I come across that
>construct I have to wonder why it's not called in scalar context. The '$'
>would seem to imply it should.
Huh? No more than
$x = scalar reverse fn();
would cause reverse() to call fn() in scalar context. The re
>Method calls should interpolate in double-quoted strings, and similar
>locations.
>print "Today's weather will be $weather->temp degrees and sunny.";
>Would deparse to:
>print 'Today\'s weather will be '.$weather->temp().' degrees and sunny.';
So, the -> operator is supposed to get e
On Fri, Sep 15, 2000 at 07:24:39PM -0500, David L. Nicol wrote:
> > The only decision, then, is to decide which context to use; if it
> > deparses to concatenation then it seems logical to use scalar context.
> > This also makes sense in that you can force list context with @{[
> > $weather->temp
> The only decision, then, is to decide which context to use; if it deparses
> to concatenation then it seems logical to use scalar context. This also
> makes sense in that you can force list context with @{[ $weather->temp ]} if
> you really wanted it.
$ perl -le 'sub w{wantarray?"WA":"WS"};pr
On Thu, Sep 14, 2000 at 07:49:32AM -0700, Nathan Wiger wrote:
> > > print 'Today\'s weather will be '.join($", $weather->temp()).
> > > ' degrees and sunny.';
> > >
> > > However if temp() calls wantarray(), the result will be FALSE (scalar).
>
> I think what he's trying to get at i
Michael G Schwern <[EMAIL PROTECTED]> writes:
>
>print "Today's weather will be $weather->temp degrees and sunny.";
>
>This does not DWIM. Instead of interpolating C<$weather->temp> as a method
>call, it comes out as C<$weather.'->temp'> and is usually followed immediately
>by the questio
> This topic is actually covered, albeit far less in-depth and lumped with an
> unrelated change, by Nathan Wiger's RFC 103, just in case you weren't aware.
Yeah, I've got to split those up. I was trying cut down on the flood of
RFC's that poor Larry has to sift through :-(, but they are both com
This topic is actually covered, albeit far less in-depth and lumped with an
unrelated change, by Nathan Wiger's RFC 103, just in case you weren't aware.
On Thu, Sep 14, 2000 at 03:57:41AM -0400, Michael G Schwern wrote:
> Methods will be run in scalar context. A method which returns a single sc
=head1 TITLE
Interpolation of method calls
=head1 VERSION
Maintainer: Michael G Schwern <[EMAIL PROTECTED]>
Date: 14 Sep 2000
Version:1
Mailing List: [EMAIL PROTECTED]
=head1 ABSTRACT
Method calls should interpolate in double-quoted strings, and similar
locations.
30 matches
Mail list logo
