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?

Update 3:

I am trying a new version of description of this in my scratchpad.

Update 2:

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

# Class definitions, hierarchical:
# (Not exact syntax.)

# Variables are typed. The 'ShowPriority' part hints
# to the GUI if they are to be emphasised.

ClassDef    name=Chassis        sup=CWSpace        type=abstract

    DefVal    name="vehicletype"    type=enum        inherit=true
            ShowPriority=high    enumvalues=(car motorbike trike)

    # These depends upon other objects.
    # (Code updating these is called when they changes.)

    DefVal    name=acceleration        type=int    inherit=true
    ShowPriority=( 0 high  5 low  default normal) #(Hints to GUI.)

    DefVal    name=maxspeed            type=int    inherit=true
            ShowPriority=high
    DefVal    name=maxload     min=0    type=int    inherit=true
            ShowPriority=high    #(Maxweight)

    # Objects below in hierarchy checks these.
    DefVal    name=FP        type=bool    usermod=true    inherit=true
            ShowPriority=high    description="Fire Proof armor?"


# (And lots of other details.)

EndClassDef

# ...

# This is a (simplifed) specification for the Driver
# object, which is added automatically to a design.

# The 'allowbelow' list specifies those objects that
# are lelal sub-objects to Driver. (Those that
# classify themselves as 'personal'.)

# The '_class_0-1' is a specification of the number
# of objects allowed.

ClassDef    name=Driver    sup=People    type=obj
        allowbelow= ( personal _class_0-1 )
    setDefaultValue    name=space    value=2    ShowPriority=low
    setDefaultValue    name=weight    value=150  ShowPriority=low
EndClassDef

# There are some code overrides that check additions
# below the Driver object, too.
[download]