like:
my $p=use Derived(...flags+arglist) -- then it's import routine could
call 'new' and do it's initialization of 'Basic' (a Base Class), then
return the initialized object from 'use'.
That's sorta what I'm wanting -- I want the objects, but I also want the precompiler stuff in use params (as in use mem (....BEGIN code);) or in a BEGIN block.
I recently came back to work on some of my perl progs that broke after upgrading some system utils. Before that I was working in C++11 and getting some exposure to C++14. So coming from that back to perl. CC++11 has that entire Turing complete template preprocessor, that people have written LISP interpreters in and the game of life. And that's just the front-end (equiv to old 'cpp' that handled the #defines and such). So when I started thinking of how I wanted to fix up some modules, it's very possible I was or am being influenced by my c++ work. I know perl isn't c++, but ... I was thinking of trying to use closures to hold the options. If the "import" and the routines needing the flags at runtime are both in the same closure, things set by 'import' should be accessible from the runtime "pointer-getter". I have no idea if it will work but I seem to remember in one of the perl books reading about it being possible (2nd ed. of Effective Perl programming...).
So not exactly trying to re-invent it -- just do it a different way. Similarly, some use data-objects "inside out"...and that is also called OO. So one could look at this as another way to deconstruct the problem space in order to get the advantages of having objects defined in the BEGIN stage. I.e. for vars in Data::Vars, some semantic checks can be done: assure names were declared and create accessors so if any members are misspelled or plain non-existent, an error can be issued.
Right now there is an inconsistency w/o non-members are handled at init time vs. run time, but that's because I don't have a a way to store "flags" (or options) in my "use" statement yet. But errors in initialization are ignored to allow for/support inheritance. Vs. in the executable code, the developer gets an error at compile time. (which is why 'Derived' did it's accessing of 'nine' in an eval).
Data::Vars also allows default initialization values, and does type checking of blessed references if you try to assign over them:
perl -we'use strict;use Data::Vars [qw (x y z)]; bless my $y={one=>1, two=>2}, q(hash); my $p=__PACKAGE__->new({x=>[1,2,3], y=>$y}); if ($p->x(0)+$p->x(1) == $p->x(2)) { $p->y($p->x) }' Warning: var type redefined from "hash" to "" at /home/law/bin/lib/Dat +a/Vars.pm line 113. Data::Vars::_Var(undef, 1, 2, 3) called at -e line 4
It isn't always an error, but often is. Yet, again, the need for turning off some behaviors not only by module but, *ideally*, lexically, though I have no clue about how to do that right now, just getting them to work reliably at the module level would be a great 1st step. Does that make more sense?
In reply to Re^4: Design question: storing package 'flags'.
by perl-diddler
in thread Design question: storing package 'flags'.
by perl-diddler
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |