Handling Bindings for Perl variables

["Bradley M. Kuhn" <bkuhn at ebb dot org>]

Per Bothner <per@bothner.com> wrote:

> > Hm.  My guess is that it might be better to use Bindings.  That is
> > each Perl "package" would be its own Environment, and for each
> > identifier in that package (a typeglob?) you have a Binding instance.
> > This does mean you have be able to associate separate scalar, array,
> > and hash values with a given Binding,
 
> On further thought (and reading of the Camel book), you probably want
> separate Binding instance for the scalar, array, and hash variables.

I agree, that is definitely needed, particular to handle ties.  However,
there probably needs to be another layer of indirection as well to handle
things like glob assignment:

    *a = *b

will cause $a, @a, %a to be aliases for $b, @b, and %b, respectively.

So, I was thinking that there would be a subclass of Binding, called a Glob,
that would contain Binding entries for each type of variable that can be
held in that Glob.  This would make operations on Globs easier.

However, am I overthinking this?  Should I instead just implement Glob
operations like "*a = *b" by generating code to find all these entries and
put the right Constraints in place?


Also, on another matter, I didn't see a way to easily use existing Bindings.
I looked at Binding2, as that seemed the closest to what I'd have to do for
Perl variables.  However, it seems there is a lot of things hard-coded in
gnu.expr.* to make Binding2.  Are you planning to generalize that structure,
or should I try to make do with some sort of hack?

Could I perhaps help generalize what is there?

> As I said in my previous message, I don't think this will work.  One
> reason is that theer is no guarantee that all names in a given package
> will be defined in a single Perl module - and you can't add new fields to
> an existing Java class.  The other reason is tied variables.  You want to
> be able to intercept a variable reference - without knowin in advance if a
> variable is or will be tied.  So use Bindings - they can handle that
> easily.  To tie a scalar variable (for example), you define a new
> sub-class of Constraint, such that get and set methods call the
> appropriate Perl class.

This sounds like a good idea.  I am curious, though, how to handle both
lexicals as well as globals this way.  How do you see having these bindings
set up?  Should each scope have an Environment, too?  Should I just declare
lexicals as Binding objects in the given scope?

If you can point me in the right direction on how to use Bindings to handle
globals and Lexicals, I'd appreciate it.


For global variables, one idea that I had for was to create an superclass
for all Perl modules:


interface PerlModule {
   Environment moduleEnv;

   Binding getScalarByName(String name) {
       // lookup scalar in Environment;
   }

   Binding addScalarByName(String name) {
       // add scalar name to the Environment;
   }
}

Or something like that.  That way, it would be easy for a Java programmer or
even Scheme programmers to get at Perl variables in a module.

Does that seem reasonable?

-- 
Bradley M. Kuhn  -  http://www.ebb.org/bkuhn

PGP signature