|P is for Practical|
What should I name my module?by BerntB (Deacon)
|on Sep 07, 2005 at 23:56 UTC||Need Help??|
BerntB has asked for the
wisdom of the Perl Monks concerning the following question:
Where in the module name hierarchy should my code go?
I've (almost) written a simple modelling system (not "OO modelling", as in the comp-sci term). It is used to model something that can be described by a hierarchy of objects. The objects, the rules for inheritance and so on are defined by code and configuration files.
I wrote this specification system to implement the design part of an old favorite game from long ago, which AFAIK has never been fully implemented before. (-: Yes, this was one of my life goals. :-)
It was quite hard to write the design framework and it should be a good fit for other modelling problems. I have no idea what this will be usable for, outside of over complex board games.
So where in the module name hierarchy should my code be? Hardly in "Game::"?
I'm now writing a simple CGI user interface and will have to write a new example with new .t files (my only real example is for that game, which is copyrighted) -- and then it is finally first upload to CPAN!
So, a second question is -- any neat Monk nodes about how to package the small CGI test application for install?
I am trying a new version of description of this in my scratchpad.
Monks has pointed out that the above description was much too vague to give naming advice. :-)
OK, here is another definition.
The problem I wrote this for was designing a vehicle in a game. It is a hard problem that no one ever solved, because there are lots of rules with lots of exceptions.
1. Consider mapping the vehicle design onto an XML document, with the tags as parts (physical or logical) of the vehicle.
2. Then let the XML tags be objects. Let the objects have an inheritance hierarcy, too. (Something like building a graphical interface from objects, where you subclass e.g. a Pane class and add your own specific data.)
3. Now you can have lots of standard behaviour and override the behaviour in local places -- in a way that doesn't result in too d.mn complex code.
4. Add some simple logic for letting a changed value in one object influence other objects (like a spreadsheet), rules for allowing a hierarchy of objects, etc.
5. Voila, a design system that can model quite complex rule systems. But not a simulation handler, because there is no concept of time, etc. It is just the Model part of a MVC.
There should be similar systems, but I've never heard of them. For some kind of problems, this should be very good.
(-: If this really is new, which I doubt, wonder if some US Monks are writing a patent application right now...? It should be patentable over there. :-)
A definition of an object in the hierarchy is going to look something like this. So there is an inheritance hierarchy of objects. Then there is a build hierarchy. What objects can be above/below others are specified. Lots of other rules are also added.