This is the mail archive of the kawa@sources.redhat.com mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Different results with eval and compileToFiles()


Per Bothner <per@bothner.com> writes:

> 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 would like to set things up so that there is a class for each Perl package
> (compiled to ModuleExp), and each class has static variables (using
> Declaration fields in the ModuleExp) for all these "global" variables.

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.

I'm not sure how you'd handle Perl arrays and hashes.  They seem to
be this strange hybrid between values, and variables.  You might
implement than using Bindings, then automatically create or
extend an array object.  
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]