in reply to Design question: storing package 'flags'.

Is this correct?: You want a module that can be configured to do stuff differently depending on how it's configured. And you may want to have two or more of these configurations at the same time in the same program. (Otherwise you probably wouldn't worry about clashing variables.)

To me it seems like you want an object/class. 'instance1' of the object does it this way, 'instance2' of the object does it that way. The customization can then be done during class initialization and then you pass the class instance around and do stuff.

The following code is only for illustrative purposes. It is incomplete and will not compile. Assume 'Find::Files' is an actual module and does whatever you want it to do.

# first instance sub magic1 { ... } my $obj1 = Find::Files( 'function' => \&magic1 ); # let's do some magic! $obj1->find_and_call_function('/tmp'); # ------------------------------------------------ # second instance # can be in the same file or in another module sub magic2 { ... } my $obj2 = Find::Files( 'function' => \&magic2 ); # let's do some other magic! $obj2->find_and_call_function('/tmp');

Replies are listed 'Best First'.
Re^2: Design question: storing package 'flags'.
by perl-diddler (Chaplain) on Jul 13, 2015 at 11:37 UTC
    @Monk:Thomas asked: Is this correct?

    Um, I think you forgot the part where the parameters are passed in the use statement, so their values are available in the 2nd pass.

    This is about the smallest snip I could create. It's a totally *concocted* case but one that does illustrate some of the things I was talking about.

    I think I've gotten the answer to my question -- since no one jumped up and said "oh yeah, use the XXYZ module" or "why don't you just use the "%+" operator that is made for things like this...(i.e. I was thinking this was hard, and wanted to make sure I wasn't missing something). But in the following example,


    main "is a" Data::Vars and is a 'Derived'.
    Derived "is a" Data::Vars and is a Basic.
    Basic "is a" Data::Vars. All are assigning their values to members of the 'struct' that has member's labeled 'one', 'two', 'three'...eight.

    'Derived' tries to assign something to 'eight' at definition time, and 'nine' at execution time. The attempt to assign a value to eight creates no error or warning by default with the idea that it might be legal in a more 'base' class (though was thinking of having a need for a flag (!!!) that might tell it to give an error anyway). I.e. the module might change it's configured behavior based on parameters.

    As a whole, in this while 'main', Derived, and Basic try to assign to the 'blessed HASH' $p:

    • 'main' assign Roman numerals
    • Derived assigns floating point numerals w/".2" added to their named value.
    • Basic tries to assign arabic numerals
    Since they don't all assign to the same members of the set, one can see the precedence of the inheritance and a sample 'motive' for wanting to pass the flags/params along with normal params == i.e. it would be much more useful if I could pass ':format=float|arabic' as a flag and have the data converted at runtime rather than being hard-coded as it is in this example. Here's the code:
    #!/usr/bin/env perl use warnings; use strict; { package Basic; use warnings; use strict; use mem; use P; our @flags; use mem (@flags = qw(one two three four five) ); use Data::Vars \@flags, {one=>1, two=>2, three=>3, four=>4, five=>5} +; sub Decimal() { my $p=shift; P "\nDecimal:p=%s", $p; my $q=__PACKAGE__->new(); $q->three="change 3 to 33/11"; P "Decimal: (one, two, three)=(%s, %s, %s)", $q->one, $q->two, $q- +>three; } } { package Derived; use warnings; use strict; use mem; use P; our @ISA; use mem (&{sub() {push @ISA, q(Basic)}}); use Data::Vars [qw(one two seven)], {one=>1.2, two=>2.2, seven=>7.2, eight=>8.2}; sub new ($) { my $p = shift; my $c=$p||ref $p; bless $p = Basic->new(@_), $c unless ref $p; $p = $p->Data::Vars::new($p); } sub Float() { my $p=shift; P "\nFloat:p=%s", $p; my $q=__PACKAGE__->new(); $q->three="Float: 3.3"; $q->four="Float: Derived 4.4"; my $val = eval { $q->nine="Float: 9.9"; }; if ($@) { P "\nassign to nine got:\n%s\n", $@; } P "Float:q=%s", $q; } 1} package main; use warnings; use strict; use P; use Data::Vars [ qw(one three four) ]; bless my $p = __PACKAGE__->new({one=>'I', three=>'III', four=>'IV'}); P "main:1: p=%s", $p; $p = Derived->new($p); P "main:2: %s", $p; $p->Decimal; $p->Float;

    And it's output:

    > perl multiuse.pl main:1: p=main{four=>"IV", one=>'I', three=>"III"} main:2: Derived{five=>5, four=>"IV", one=>1.20, seven=>7.20, three=>"I +II", two=>2.20} Decimal:p=Derived{five=>5, four=>"IV", one=>1.20, seven=>7.20, three=> +"III", two=>2.20} Decimal: (one, two, three)=(1, 2, change 3 to this txt) Float:p=Derived{five=>5, four=>"IV", one=>1.20, seven=>7.20, three=>"I +II", two=>2.20} assign to nine got: Can't locate object method "nine" via package "Derived" at multiuse.pl + line 37. eval {...} called at multiuse.pl line 37 Derived::Float(Derived=HASH(0x8e5648)) called at multiuse.pl line 56 Float:q=Derived{five=>5, four=>"Float: Derived 4.4", one=>1.20, seven= +>7.20, three=>"Float: 3.3", two=>2.20}

    Comments: ...

    Sorry... ran out of hit points again. Some of the comments and my rational should be more clear now (crossing fingers).... I do understand that this could be a bigger pain that I might want, BUT, I really wanted the 'flags' to mostly pass true/false values (debug, 'useperlonly'...etc).. but then I got to thinking why I shouldn't support other values... and if I didn't, how much might I flagellate myself for laziness. ;-/

    Hope the above isn't too bad to look at... I just realized, that it won't run because Data::Vars isn't in CPAN. It's not that it is buggy, in fact it is fairly mature, but I don't consider it ready until I'm sure I've solved issues *exactly* like this -- the need to pass different flags for different behaviors at runtime.

    If enough people want to try it, I think I can not have it index by CPAN if I put a letter in the VERSION? But I didn't want you to be in the dark about what I was trying to do and why, so forced myself to at least type up this much and create a simple demo case.

    -l

      I'm trying to wrap my head around this and I'm wondering whether you are trying to reinvent objects / classes. The phrase 'available for the second pass' sounds very suspicious. Additionally you already play around with @ISA and blessed.

      Have you read about object orientation in general and Moose / Moo in particular?

        Well, reinvent... not exactly. But earlier I mentioned that I was wondering if I needed to do something to capture a object handle from 'use',

        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?