in reply to Re^4: Rather WeirdDataModeller
in thread What should I name my module?

If it's a generic tool for dealing with hierarchies of things, maybe Tree:: would be a good place? I think Model:: would too generic -- better to try to describe what it is or does. (The "noun::adjective" style). As a last resort, maybe something under Data::. (c.f. Data::Grove or Data::Hierarchy.)

-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.

Replies are listed 'Best First'.
Re^6: Rather WeirdDataModeller
by BerntB (Deacon) on Sep 08, 2005 at 03:12 UTC
    Thanks, sounds good.

    Not "Simulation", since there is nothing like timing implementation, etc. What should fit would be object modelling, without people thinking about the programming subject "OO modelling".

    'Tree::Model' ?

    In retrospect, this is too large. I should have written a sub-level of CPAN packages and used them for the implementation. (Say, the object keeper with serialization, etc, should have gone to CPAN as a module first and then I could have use:d that.)

      Tree::Model is still too general. What I'd want to understand from reading a name is what it distinctive about your module. From the bits you've said so far in this thread, I'm still not particularly clear what it does. Can you explain further? Can you post a link to a Pod file?

      So far, the best I can come up with is something like Tree::PartsAssembly or Tree::PartsCollection or Tree::ComponentParts

      -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.

        Thanks, good ideas!

        I added a long description as an Update to the first post. I think that should clarify?