Class

Not sure if this will be more than a way to think about types as more than a single thing. In Decko, you can think of right rules and code as implementing something analogous to mixin types and you would build the methods, views and attributes of the mixin type. In this way, adding a child to a Card (plus card) would add a mixin type or funcionality subset. The other class paradigm is Classes with Inheritance. Card Modules can share code based on any of the Ruby class abstractions at the mod level (Monkey code in Ruby), and Cardtypes connect to the internal core and extended classes via the default and structure rules, but anything beyond that is Sharking conventions. In the tickets at decko.org, there is a set of cardtypes with related/overlapping object models, which basically amounts to synchronization of UMLish object models, i.e. they share children of same names/meanings.

For this concept I was thinking for now just to be able to document what is shared by members of a class. Initially I was thinking a Class instance would be a Pointer whose elements are Cardtype cards, but want to expand that with the Set type (at least until it proves to be useless or unworkable) So, sets like: Intent+*type and intent+*right might be linked as a Class with same attributes and relations to other Classes. I think we are going to be well beyond a lot of standardized tools using UML, and a lot of what we do here will be an experiment. Having UML toolchain support is a longterm goal that we won't have a lot of in the beginning. To the extent we can connect to existing tools (e.g. Eclipse and other OS and pro CASE tools) and extend a general community like Umple that is great, but a bonus to the core work.