>Currently, the current object context is passed into a sub as the first
>element of @_, leading to the familiar construct:
> my $self = shift;
>However, this is a big PITA. In particular, if you support lots of
>different calling forms (like CGI.pm), you have to check whether $_[0]
>is a ref,
>It's a pain if you want to support both function-oriented and
>object-oriented calling forms, as CGI.pm does. For example, you can use
>both of these:
> print header;
> print $r->header;
>with CGI.pm. Now you need a self_of_default special method, since
>sometimes $_[0] has a class ref and
>Jonathan Scott Duff wrote:
>>
>> >Operator Overloading
>> >-
>> >PLUS Called in + context
>> >MINUSCalled in - context
>> >TIMESCalled in * context
>> >DIVIDED Called in / context
>Come on Tom take it easy on us poor admins who have to live in the "Billduh"
>world.
So long as such folks do nothing that will hurt those of us who
have no trek with such, then live and let live. But when Billness
starts biting those who won't have anything to do with it causing strange
acti
>You could overload
> FILE < STRING
>to be a print operator returning a FILE so we can do C++ like
> cout << "hello Bjarne" <
Summary: I think these should all simply break down into a single
Boolification test of some sort, as occurs already with operator
overload.
>LOGHIGHAND Called in && context
>LOGHIGHOR Called in || context
>LOGLOWAND Called in and context
>LOGLOWOR Called in or context
>LOGIFE
>I think they would *improve* readability. Certainly over $_[0], and
>even over:
> sub method {
> my ($self, @args) = @_;
> ...
> }
>I'm *forever* writing that and just it clutters up the code.
What about
sub somename : method (@args) {
...
>I can currently overload + < > * to do this, but not &&. That's broken.
Hm I don't recall C++ ever thinking to overload the control-flow
operators ("&&", "||", "," (that is, comma), and "?:"). Why not?
Even if their "a && b" should produce a more mundane 1 or 0, one
still might wish contr
>Or if clearly make basic types look *very* different from user-defined
>types:
> my Dog $spot;
> my *int $i; # types that start with * are "basic"
Intrinsics (basic types) are in lower-case.
User-defined types aren't.
our num $Count;
my Word @verbs;
One wonde
>Do you really mean to suggest that $SPECIALVARS be (by convention)
>uppercase but built in types be (by grammar) lowercase?
Absolutely. That's how it's already worked. The pragmata are lowercase module
names are reserved to the Core. The type name is the class name, which
is the package nam
>Well, remember that BEGIN{} blocks are just subs too, with an optional
>'sub'.
Not exactly. They are not callable, as they disappear immediately.
More importantly, they have no @_, and things like pop and shift
act upon @ARGV from within them.
The compilerish chapter of the Camel calls them bl
>=head2 Private methods
>The C keyword could also be applied to subroutines, to restrict
>where they may be called. Access rules similar to those for private hash
>entries would apply:
>package Base;
>
>sub new { ... }
>
>private sub check { ... }
>
>=head1 REFERENCES
>Christiansen & Torkington, I, pp. 470-472.
>Conway, I, pp. 309-326.
One might add refs to Camel-3's new OO chapter on privacy approaches.
--tom
What happens on reblessing?
--tom
>The whole notion of blessing is non-obvious enough already.
It's the benedictory (con)not(at)ion of blessing, not the bless()ing
itself that so confuses people, I think.
It bless() were instead named something like
mark
stamp
label
brand
retype
denote
notate
> exists (sometimes causes autovivification, which affects C)
That's not technically accurate--exists never causes autovivification.
--tom
> > > exists (sometimes causes autovivification, which affects C)
> >
> > That's not technically accurate--exists never causes autovivification.
> print keys %hash, "\n";
> exists $hash{key}{subkey};
> print keys %hash, "\n";
>Or did that get fixed when I wasn't looki
>On Tue, 05 Sep 2000 19:08:18 -0600, Tom Christiansen wrote:
>>> exists (sometimes causes autovivification, which affects C)
>>
>>That's not technically accurate--exists never causes autovivification.
> print exists $hash{foo}{bar}{baz};
>
>That's not required. All that is necessary is for C nodes
>in the op tree to propagate a special non-autovivifying context to
>subordinate nodes.
That seems reasonable--except that I don't believe exists() merits
any special treatment.
--tom
>That seems reasonable--except that I don't believe exists() merits
>any special treatment.
More specifically, I think all non-lvalue context use of -> should be
non-autoviv, whether exists or anything else.
--tom
>I agree entirely.
>In fact, I shall extend RFC 128 to allow subroutine parameter to specify
>that they are non-autovivifying.
I'm not sure why it matters to the subroutine. We've already got the hack
so that
fn( $a[$i] )
or
fn( $h{$k} )
will only autoviv those puppies if you muddle
>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
>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
>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
># $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 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.";
>
>> 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
>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
>So what about
> print "Thanks, $user->{'first name'} for your order!";
>Which needs nested quotes already?
printf() is more readable in such cases.
--tom
>This RFC proposes that rather than three separate mechanisms (in three
>separate namespaces) to determine object typing information, Perl 6
>simply extend the C function to return all the necessary
>information in a list context.
That sounds nice. It would also cure the funny business I tacitly
>As Nate pointed out: print "$hash->{'f'.'oo'}" already works fine and
>the world spins on.
That is no argument for promoting illegibility.
--tom
>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.
>We've had prototyping (context coercing) for methods as long as we've
>had them for "ordinary" subroutines.
Sure -- they just don't work.
Method calls are indirect function calls. As such, they are not
resolved until run time. Context coercion, however, is set at
compile time--if at all.
--
33 matches
Mail list logo
