Re: Constants and Subclasses...

I think you can make it work if you derive your base class from an exporting-capable module, like Exporter. In this case, declare an @EXPORT array with the things you want the children classes to know about. In the code of the child class, invoke import() so that FOO can be known without further qualification.

package ParentClass;

use base qw(Exporter); # requires and adds Exporter to @ISA
BEGIN { our @EXPORT = qw(FOO); } # what must be known elsewhere

use constant FOO => 'foo';

package ChildClass;

use base 'ParentClass';
BEGIN { P->import(); } # import FOO

sub doStuff {
  my ($self, @otherArguments) = @_;

  print FOO; # should work just fine
  print $self->FOO; # just the same as above

}
[download]

Update: jettero and diotalevi pointed the flaws in my first versions of this answer. It was much harder than I thought at first to get it right. The BEGIN's blocks are absolutely necessary to make it work.

Comment on Re: Constants and Subclasses... Select or Download Code

Replies are listed 'Best First'.
Re^2: Constants and Subclasses... by diotalevi (Canon) on Dec 18, 2006 at 18:37 UTC
That's not going to work for anything that inherits from ChildClass. It also doesn't work if the inheritance relationship changes after compile-time. [Added: You also forgot to import &import from Exporter or make the parent class an ISA of Exporter.] ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊	[reply]
Re^3: Constants and Subclasses... by t'mo (Pilgrim) on Dec 18, 2006 at 20:39 UTC
In general, I don't want to do anything as hairy as changing inheritance relationships during run-time. :-) ...every application I have ever worked on is a glorified munger...	[reply]
Re^4: Constants and Subclasses... by diotalevi (Canon) on Dec 18, 2006 at 21:12 UTC
Yes, but this is perl so it's allowed to happen and you might need to be prepared if it's ever done unto you. ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊	[reply]
Re^2: Constants and Subclasses... by diotalevi (Canon) on Dec 18, 2006 at 19:59 UTC
BEGIN is only necessary because you're doing this all in a single file and need to hack the order of execution. This wouldn't normally be an issue in real code. Also, if you switched to use Parent; @ISA = 'Parent' instead of base.pm then you wouldn't need to separately call import. Further... making the parent export it's constants means that all other code that merely uses Parent will also get the constants exported and that's likely not what you want. ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊	[reply]
Re^3: Constants and Subclasses... by ferreira (Chaplain) on Dec 19, 2006 at 11:45 UTC
I understand this more fully now after sleeping over it and after your excellent explanation and alternative with `use Parent; @ISA = 'Parent'`. (But — in the single file case — realize I cannot `use` because that will call `require` which will try to read `Parent` from a file. In turn, `use base` apparently doesn't do this if it notices the package is already there — not relying only on `%INC`.) With respect to the unwanted exportation of the constants, it might be better to implement this as suggested by jettero (Re^2: Constants and Subclasses...) and do: `our %EXPORT_TAGS = ( CONSTANTS => [qw(FOO)], # and other constants ); our @EXPORT_OK; Exporter::export_ok_tags('CONSTANTS'); # populate the @EXPORT_OK` [download] and then `BEGIN { P->import(':CONSTANTS'); }` [download] As the constants are not exported by default anymore, the user of the code should explicitly call for them or not. Yeah, jettero, you were right from the beginning about the convenience of `@EXPORT_OK` and `%EXPORT_TAGS`.	[reply] [d/l] [select]
Re^4: Constants and Subclasses... by diotalevi (Canon) on Dec 19, 2006 at 17:47 UTC
No... the most correct way to do this would be to use the normal class method syntax. This is OO so it's entirely likely that someone's going to want to subclass that constant at some point. Your static exporting circumvents inheritance. ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊	[reply]
Re^2: Constants and Subclasses... by jettero (Monsignor) on Dec 18, 2006 at 18:33 UTC
Does require call the `import()`? In any case, I was about to answer the Exporter, but I think to make that less sucky you'd want to use EXPORT_OK and/or EXPORT_TAGS instead. So the child class could use them explicitly if it wanted to. That's probably pretty obvious I guess. But, I always `use base qw(Exporter)` to get the exporting to actually happen. I've never tried it with require. Does the require work? [update: thanks ferreira] -Paul	[reply] [d/l] [select]
Re^3: Constants and Subclasses... by ferreira (Chaplain) on Dec 18, 2006 at 18:51 UTC
No, `require` does not call `import()`. And you reminded me I wanted to include Exporter in the `@ISA` array so that the parent class inherited the `import()` method from Exporter (which is why this module came into the answer). This is almost equivalent to `use base qw(Exporter)` (but not identical). See the docs of base. Also, if the symbols were added to `@EXPORT_OK`, they should be explicitly mentioned as arguments of `import`. To keep the answer in line with the question, using `@EXPORT` is the easiest thing to do.	[reply]