develooper Front page | perl.perl6.language | Postings from July 2005

block owner, topic and the referential environment

From:
=?ISO-8859-1?Q?=22TSa_=28Thomas_Sandla=DF=29=22?=
Date:
July 27, 2005 01:30
Subject:
block owner, topic and the referential environment
Message ID:
42E7461D.5060801@orthogon.com
This is another spin-off from the 'Exposing the Garbage Collector'
thread. Here is an enhanced version.

I wonder how the generic, lexically scoped invocant/owner is called.
I propose to call it $/ (other option is to call it $&)and let the
former topicalizer become block owners and $_ the block topic that flows
into blocks from further outside if not explicitly bound with -> like:

    $topic := Some.new;
    $_ := $topic;
    for @objects { .action } # call on $/ from @objects with $_ := $topic
                             # in all loops

    @objects┬╗.action;  # same for single action syntax


    # but
    for @objects -> { .action } # means $/.action($/) because
                                # $_ bound to dynamic block owner;
                                # but usefull for methods that don't
                                # use the topic, in particular accessors
                                # and mutators
    # same as sub call
    for @objects -> { action }  # means action($/) because $_ := $/
                                # but $/ is there if action is of
                                # type Method

    # but the $. @. %. and &. are bound through $?SELF
    # in particular
    for @objects -> { &.action } # subref curried on invocant

This implies that a .action means name lookup of 'action' while
&.action is an onboard method of $?SELF. This latter case is
typically implemented with a vtbl lookup.

The only drawback I see is, that the careless method programmer could be
caugth in an endless .action loop if .action invokes .action explicitly
on $_ where $_ := $/ from the outside. The same endless loop could of
course be achieved with a free standing .action but that looks more like
intention.

With the lurking pitfalls an occasional check of $_ =:= $?SELF and
$/ =:= $_ seems advisable and indicates that the invocant wasn't
exchanged midway :)

Same with other block topicalizers/owners

   given $x    {...}  # topic untouched, but $/ := $x
   given $x -> {...}  # $_ := $x as well

But

   if $x    {...}   # $/ and $_ untouched
   if $x -> {...}   # $_ := $x (non boolean value)

One more interessting thing is that in exception handlers all three
variables $!, $/ and $_ are in scope. This might allow to resume where
the exception occurred after the cause was fixed e.g. by loading or
generating some code, some revamping or other &DEEP_MAGIC. Hmm, debug
exceptions come to mind...
-- 
TSa (Thomas Sandla├č)





nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About