Unfortunately (though many think it a feature), your point 3. is correct. The declaration of %ENTITIES as a lexical gives it file scope only. Without some sub forming a closure by returning it or a reference to it, it is invisible outside the file.

There is a half-measure you can take. The functions exported by MathML::Entities need not be imported, and you can define your own %ENTITIES and functions like so:

package 'MathML::Entities::Approximate';
use MathML::Entities (); # explicit no-arg stops import
my %ENTITIES = (
    foo => '&x000042',
);

sub _convert2numbered {
    my $reference = shift;
    $reference =~ /^&([a-zA-Z0-9]+);$/;
    my $name = $1;
    # above copied from MathML::Entities
    return exists $ENTITIES{$name} ?
        $ENTITIES{$name} :
        MathML::Entities::_convert2numbered($reference);
}
# etc.
[download]

Another choice would be to just copy the MathML::Entities code to your module and modify it there. That's not very different from the above code, and probably simpler.

Another choice would be to just copy the MathML::Entities code to your module and modify it there.

Indeed - or I could simply hack the changes I want into M::E itself (which I have done on my workstation, for development purposes).... but that kinda defeats the purpose of having proper Packages <grin />)



-- Ian Stuart
A man depriving some poor village, somewhere, of a first-class idiot.

I would provide some set of accessor functions to, at least, add entities to %ENTITIES. Then, I would submit the patch back to the author along with some tests. Remember - in OSS, if you want something done, the quickest way is to do it yourself. That's why you have the code.

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

These question suggest that there are some basics about Perl OO that you're missing. You might want to see Perl Object Oriented Meta-Tutorial for pointers to where to start. For example, to subclass, you'd need to make sure the argument to base is in quotes:

use base 'MathML::Entities';
[download]

However, for your question about making functions available, you just need to make sure the functions are imported in the first place, and then specify them to be exported. For that, you have to do it longhand, you can't use base as that doesn't import any functions.

package MathML::Entities::Approximate;
use strict;
use MathML::Entities qw(function1 function2); # import the desired fun
+ctions
use vars qw( @ISA @EXPORT );
@ISA = qw( MathML::Entities Exporter);
@EXPORT = qw( function1 function2 ); # re-export them
[download]

Unfortunately, to the last point, if %ENTITIES is a "my" variable in MathML::Entities, you can't access it directly without "breaking the rules" using something like PadWalker.

These question suggest that there are some basics about Perl OO that you're missing.

Absolutely! I've spent two years in JavaLand, and forgotten all the nifty Perl stuff that was in my head..

Unfortunately, to the last point, if %ENTITIES is a "my" variable in MathML::Entities, you can't access it directly without "breaking the rules"...

I can't even access it to make a copy, can I? - no way of making %M::E::A::ENTITIES ?

If I understand it correctly, if %ENTITIES was an "our" variable, I could have added data to it - and the E::M methods would have accessed the now-longer-hash, yes?



-- Ian Stuart
A man depriving some poor village, somewhere, of a first-class idiot.

I can't even access it to make a copy, can I? - no way of making %M::E::A::ENTITIES ?

Think of a "my" as similar to "private" data in Java (if I remember my Java, that is). It's pretty much totally inaccessable without using XS to violate the encapsulation and troll through the Perl guts directly. Your best bet may be to do a copy/paste into your subclass and modify it that way. Ugly hack and dependency, but probably the sanest alternative if you really need it.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.