I see this kind of thing a lot in my work - we often assume that "type" means class, but as a design progresses we realize maybe it isn't after all, or maybe it is some sort of hybrid, or ...

In sorting out these sorts of problems, it is important to realize (as I think you have) that "meta" is relative. It is always meta to something else and we can have layers upon layers of meta. Just check the UML specs if you don't believe - if I recall there are 3 or 4 meta layers in that model alone, and that is just to model modelling!

So instead of thinking of these problems in terms of things, instances, classes, and types, I prefer instead to model "sets" - sets of related data, methods, and actions. To this end I recommend reframing the issue in light of the following questions. My sense is that you have a pretty good handle on 1,2,3 but are working your way through 4 and 5.

  1. what data do I need to track about X?
  2. what calculated things do I need to make with my data about X?
  3. what operations or intentional side effects do I need to do using my base and calculated data?
  4. How are the instances of X related to each other? When viewing the entire set of things that I consider instances of X how do they differ from one another? Is there a common core of data, actions, and calculations shared by all? Do subsets vary in specific ways? Is this really one class for all X instances? Separate singleton classes for each X instance? Or something in between - a superclass and a handful of subclasses? For that matter, is each instance of X really one "thing"? Or is a set of connected things? Can I explain the differences between various instances of X in terms of X's parts? Or is there something about each X instance that makes it more than just the sum of its parts?
  5. And finally for a bit of intelligent crystal ball gazing: How stable is my current set of all X? Do I have enough information to be certain? What kind of objects are likely to be added to it (given scope, user community)? Why? How are they likely to be different from the X instances I already know about? Have I studied other applications, implementations, or standards documents to see what sort of X instances they come up with?

Question 1 identifies a set of data members. Questions 2 and 3 identify a set of methods. Question 4 keeps one from jumping to either-or conclusions about class architecture. And 5 is meant to jog one loose and prevent the short-sighted-ness that creates the need for yet-another-foo-framework.

Only after you have have a clear handle on these questions, can the questions about implementation be answered. (And if you have the answers expanding your post to include them will get better feedback).

A "class" is just an object with its own special set of data and methods. Some of this "data" may be pretty funky (e.g. code references) but it is still data. Furthermore, its definition is surprisingly dependent on your chosen framework. If your answers to the above questions line up with the data and methods available for a class as defined by OOP framework Foo, then by all means use framework Foo and treat X (or instances of X) as a class within that framework. But if not, pay closer attention to questions 4 and 5 and feel free to be creative in how you use the resources of your chosen OOP framework.

Best, beth

In reply to Re: Moose, Metadata and the Everything CMS by ELISHEVA
in thread Moose, Metadata and the Everything CMS by Nomad

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.