Loading ...
Sorry, an error occurred while loading the content.

78Introducing $self ... but it's not an object yet

Expand Messages
  • jimkeenan
    Apr 3, 2010
      As reported in previous posts, (1) ExtUtils::ParseXS now
      compiles under 'use strict'; (2) I've made considerable
      progress at eliminating global variables; (3) the biggest
      remaining obstacles are the 'eval EXPR' statements.

      I don't yet have any clue as to how to eliminate -- or even
      better cope with -- the string evals. So I've tried to work
      around the problem and do as much refactoring as I can
      without generating errors.

      In particular, the latest versions of ParseXS.pm on my
      github site feature a '$self' which is a hashref declared as
      an 'our' variable, i.e., a package global like the 71
      globals previously described. I have moved 64 of those 71
      'our' variables into $self. I am proceeding on the premise
      that at a certain point we'll be able to convert $self from
      an 'our' variable into a hashref blessed into an
      ExtUtils::ParseXS class and returned as an object.

      The 7 'our' variables which I have not yet wedged into $self
      are these:

      our ( $FH, $Package, $func_name, $Full_func_name, $Packid, $pname, $ALIAS, );

      For these variables, I have not yet been able to do
      conversions like this:

      $Package --- $self->{Package}

      With the exception of $FH and $ALIAS, these are variables
      that, if transformed into '$self' attributes, incur errors
      when interpolated inside heredoc statements or string evals.

      $FH causes a problem due to the '>' sign serving too many
      purposes in Perl 5:

      while ( my $line = <$self->{FH}> ) {

      That will give a syntax error.

      $ALIAS is an unusual case. As noted in the comment
      beginning at line 545 of the current version of EUPXS,
      I feel that $ALIAS really ought to be a 'my' variable
      lexically scoped within process_file(). But when I tried
      that out over hundreds of actual CPAN distros with XS, I
      encountered two cases where that revision caused a change in
      the .c files generated by xsubpp. In both cases, the
      the .c files compiled without complaint and the distros
      passed all their tests. In fact, to my
      not-a-professional-C-programmer eyes, the resulting C looked
      better than what you get with current EUPXS. But we are
      currently committed to having revised EUPXS generate
      exactly the same C code (modulo whitespace) as current
      EUPXS, so I'm leaving $ALIAS as an 'our' variable. But I
      get errors if I try to do this transformation:

      $ALIAS ---> $self->{ALIAS}

      So, to sum up: Most of the 'our' variables have been
      stuffed into a new 'our' variable, $self, which I hope will
      ultimately become an EUPXS object. But significant
      obstacles remain, mostly located in the string evals and

      Thank you very much.
      Jim Keenan