{"id":25,"date":"2011-01-13T09:02:13","date_gmt":"2011-01-13T09:02:13","guid":{"rendered":"http:\/\/joose.it\/blog\/?p=25"},"modified":"2011-04-08T14:02:19","modified_gmt":"2011-04-08T14:02:19","slug":"joose-3-internals-%e2%80%93-part-i-meta-layers","status":"publish","type":"post","link":"http:\/\/joose.it\/blog\/2011\/01\/13\/joose-3-internals-%e2%80%93-part-i-meta-layers\/","title":{"rendered":"Joose 3 internals \u2013 Part I. Meta-layers"},"content":{"rendered":"
\n
\n
\n
\n

This post starts a series, describing the meta-model of the Joose3. It mostly purposed for people brave (or crazy) enough to hack on the internals, though casual users may find it also useful for deeper understanding of the underlaying processes in Joose.<\/p>\n

Classes and meta-classes.<\/h1>\n

Ok, lets start with the definition what is the class<\/a>. Its the abstract template or pattern, describing some behavior (for example: \u201cDog\u201d). This template can be \u201cinstantiated\u201d (usually arbitrary number of times) \u2013 that means the abstract definition receive a concrete implementation in some object (for example: \u201cPluto\u201d). Such object will be called \u201can instance\u201d of the class:\"\"<\/a><\/p>\n

<\/a>On the figure above and the following ones, the filled circles denotes classes, unfilled circles \u2013 instances.<\/p>\n

Then, what is the meta-class? Its the class, whose instances, in turn, represents classes:<\/p>\n

<\/a>\"\"<\/a>The meta-class defines the higher-level<\/em> behavior<\/em> of the class. For example it may define, that class can be only instantiated once. Or, that class may have special attributes with validation. Or, special methods with type-checking, etc.<\/p>\n

Ok. You\u2019ve probably already spotted the smell of recursion in the meta-class definition (its the class<\/em>, whose instances are classes<\/em>). Naturally, the chicken & egg problem arise \u2013 what is the meta-class of the meta-class itself? And what is the meta-class of that meta-meta-class?<\/p>\n

Joose.Proto.Class \u2013 1st meta-layer<\/h1>\n

The chicken & egg problem is being solved in Joose 3 by the 1st meta-layer, which is represented by the Joose.Proto.Class<\/a> meta-class. Joose.Proto.Class is the class, which is the meta-class for itself<\/strong>! This makes its meta-instance perfectly circular \u2013 it refer to itself.<\/p>\n

<\/a>\"\"<\/a><\/p>\n

Classes with Joose.Proto.Class meta are very close to \u201craw\u201d JavaScript and other simple class systems. Virtually everything from the class definition goes directly to the class prototype (except the \u201cisa\u201d builder). Inheritance is done with the \u201cclassical\u201d prototype chain hack (see Joose.O.getMutableCopy in Joose.js<\/a>)<\/p>\n

If you really need \u201craw\u201d JavaScript code (for animation library for example), you can host your class at this meta-level like this:<\/p>\n

\n
Class('Raw.Code', {\r\n    meta    : Joose.Proto.Class,\r\n\r\n    attr1   : 'init',\r\n    attr2   : null,\r\n\r\n    method  : function () { return 'result' }\r\n})\r\n\r\nvar i = new Raw.Code()\r\n\r\ni.method() == 'result' \/\/ true<\/pre>\n<\/div>\n
At this meta-level there are no roles, traits, lazy attributes,  method modifiers or any other magic, just JS. The other parts of the  meta-model are written as classes from this meta-level. The next post will cover this topic in detail, in the meantime we\u2019ll continue the overview of the other meta-layers.<\/p>\n
Joose.Managed.Class \u2013 2nd meta-layer<\/h1>\n
The next meta-layer is presented with Joose.Managed.Class. Joose.Managed.Class is a subclass<\/strong> of Joose.Proto.Class, and has it as a meta-class<\/strong> in the same time!<\/p>\n

\n<\/a><\/a>\"\"<\/a><\/p>\n
Important feature is that its safe to inherit from class, which has meta from the the previous layer:<\/a>\"\"<\/a>
\nThis feature makes the bootstrapping possible.
\n<\/a><\/p>\n
Classes with Joose.Managed.Class as meta-class are already very  capable. They may have  method modifiers, roles or traits applied. At  this level also appears  the Joose.Managed.Role \u2013 a special meta-class,  which, among other things, prevents class from  instantiation.<\/p>\n
However, we need one more bootstrapping step. The reason is that, by  itself, Joose.Managed.Class has a Joose.Proto.Class as meta. Thus its  behavior is very limited, you can\u2019t apply role to Joose.Managed.Class  for example. We definitely want our meta-model to have a more capable  central meta-class. Another reason is the attributes. We need to be able  to apply traits to the attributes. So the default meta-class for the  attribute should be at least at \u201cmanaged\u201d level. But this level just  been introduced \u2013 will be more elegant to delegate the change of the  default attribute\u2019s class to next layer.<\/p>\n
Joose.Meta.Class \u2013 3rd meta-layer<\/h1>\n
This is very simple meta-layer, required mostly for bootstraping purposes: Joose.Meta.Class<\/a>.<\/p>\n
<\/a>\"\"<\/a>
\nThere is also a corresponding Joose.Meta.Role<\/a> meta-class.<\/p>\n
Joose.Meta.Class is the central meta-class of the meta-model. If you  need to modify the behavior of all classes, you can apply roles to it  (comes in use for JooseX.Meta.Lazy<\/a> for example). See also next section for explanations hows that possible.<\/p>\n
Mutability<\/h1>\n
All classes in Joose, on all meta-levels are mutable. \u201cMutable\u201d means  that class\/role definition can be changed at any time (add\/remove  attribute or method for example) and the change will be propagated to  instances and other depended classes\/roles.<\/p>\n
Mutability is based on the fact, that during inheritance, prototypes  of Joose classes forms the usual prototype chain. Thats why no special  actions required when a class changes \u2013 the language itself will handle  the propagation to sub-classes. A simple example:<\/p>\n
\n
var a = {\r\n\r\n    method1 : function () { return 'a1' },\r\n    method2 : function () { return 'a2' }\r\n}\r\n\r\nvar b = Joose.O.getMutableCopy(a) \/\/ establish a prototype chain\r\n\r\nb.method2 = function () { return 'b2' } \/\/ override a method\r\n\r\nb.method1() == 'a1' \/\/ true\r\nb.method2() == 'b2' \/\/ true\r\n\r\n\/\/ mutation\r\n\r\ndelete a.method1\r\ndelete b.method2\r\n\r\nb.method1 = function () { return 'b1' }\r\na.method3 = function () { return 'a3' } \/\/ add a new method to the base object\r\n\r\n\/\/ eof mutation\r\n\r\nb.method1() == 'b1' \/\/ true\r\nb.method2() == 'a2' \/\/ true\r\nb.method3() == 'a3' \/\/ true<\/pre>\n<\/div>\n
Slightly more complex logic is required for roles mutations, but  Joose never update the whole graph of depended classes, the most of work  is delegated to JavaScript and\u00a0 number of \u201cmanually\u201d updated classes is  as minimal as possible.<\/p>\n
Conclusion<\/h1>\n
This post contains a high-level overview of the Joose meta-model. In  the next post we\u2019ll focus on the details of 2nd meta-level, which  implements the traits specification<\/a>.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
This post starts a series, describing the meta-model of the Joose3. It mostly purposed for people brave (or crazy) enough to hack on the internals, though casual users may find it also useful for deeper understanding of the underlaying processes in Joose. Classes and meta-classes. Ok, lets start with the definition what is the class. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0},"categories":[4],"tags":[7,8],"_links":{"self":[{"href":"http:\/\/joose.it\/blog\/wp-json\/wp\/v2\/posts\/25"}],"collection":[{"href":"http:\/\/joose.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/joose.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/joose.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/joose.it\/blog\/wp-json\/wp\/v2\/comments?post=25"}],"version-history":[{"count":13,"href":"http:\/\/joose.it\/blog\/wp-json\/wp\/v2\/posts\/25\/revisions"}],"predecessor-version":[{"id":275,"href":"http:\/\/joose.it\/blog\/wp-json\/wp\/v2\/posts\/25\/revisions\/275"}],"wp:attachment":[{"href":"http:\/\/joose.it\/blog\/wp-json\/wp\/v2\/media?parent=25"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/joose.it\/blog\/wp-json\/wp\/v2\/categories?post=25"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/joose.it\/blog\/wp-json\/wp\/v2\/tags?post=25"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}