Moog creates objects, with rich support for subclassing and "implicit subclassing" (like "categories" in Objective C). Moog implements the "self pattern," so you never have to worry about using
var moog = ;moog;moog;moog;
moog synthesizes objects with full support for inheritance. You can define them with any combination of synchronous and asynchronous constructors, specify default options easily, and modify options before they are seen by base classes.
To create an instance of
var moog = ;
You may also pass options:
var moog =defaultBaseClass: 'superclass';
Defines a new type.
type is a string.
definition object can contain the properties
afterConstruct, which are functions invoked by
moog.create, as described below. The
extend property allows for subclassing. All other properties are treated as defaults for the
options object provided when constructing an instance of the type.
To subclass another type, just
extend it by name in the definition of your subclass:
If you set the
defaultBaseClass option of
moog and do not explicitly
extend anything for a particular type, then that type will extend the
defaultBaseClass. If you wish to override this behavior for a specific type, just set
If you define the same class twice without setting
extend the second time, an implicit subclass is created.
The new version subclasses the old one, effectively "patching" it with new options and behavior without having to redefine everything. All other types that subclass that name now subclass the new version.
If you are not sure if there is an existing definition for the type, you can use
extendIfFirst to specify a fallback base class. This is helpful when encouraging third-party developers to optionally define a type themselves.
For convenience, you may pass an object containing properties that define many different types:
Explicitly replaces any previous definition of
type with a new one. Does not subclass the old type. If there was no old definition, this method is equivalent to
Returns true if the type is defined, whether explicitly or via the autoloader option. That is,
moog.create will succeed for
type, provided that the constructor does not signal an error. If the type is available via the autoloader, this method returns true but does not leave the definition in place.
options argument may be omitted entirely. If
options.autoload is explicitly set to
false, no attempt to test for the ability to load the type via the autoloader is made.
Creates an object of the specified
options to override any default options set in
moog;var myObject = moog;; // "My object is purple"
create is called,
moog will first call
beforeConstruct, starting with the deepest subclass first. Then the
construct methods are called, if present, starting with the base class and ending with the final subclass. Finally the
afterConstruct methods are called, if present, starting with the base class and ending with the final subclass.
In the above example,
moog.create is called synchronously, but could be called asynchronously as follows:
If it's called asynchronously, the callback receives the arguments
err, obj where
obj is the object created. If it's called synchronously, an exception is thrown in the event of an error, otherwise the object is returned. If you call
moog.create synchronously but have asynchronous
moog will throw an exception. You may, however, call
moog.create asynchronously, even if your constructor functions are synchronous.
obj will always have a
__meta property, which contains an array of metadata objects describing each module in the inheritance chain, starting with the base class. The metadata objects will always have a
name property. moog-require also provides
Creates one object of each type that has been defined via
moog.define or via the
definitions option given when configuring
moog. Only types explicitly defined in this way are created, but they may extend types available via the
autoloader option given when configuring
The options passed for each object consist of
globalOptions extended by
If you pass a callback, it will receive an error and, if no error, an object with a property for each type name. If you do not pass a callback, such an object is returned directly. If you do not pass a callback, then you must not define any types that have asynchronous
moog works in the browser, provided that
lodash are already global in the browser.
moog defines itself as
window.moog. Currently it is not set up for use with browserify but this would be trivial to arrange.
Often, it is useful for the same type hierarchy to exist in two separate instances of
moog — for instance, on the server side and the browser side. It is also often useful to recreate the same type hierarchy, but with a suffix appended to each type name.
If your server-side application has a "nifty-blog" type that inherits from "blog" which inherits from "pieces", you may want to ensure that the same types are defined on the browser side, and then take advantage of implicit subclassing to supply actual code for some or all of the types in the hierarchy.
To pull this off, invoke
moog.mirror with the
__meta property of an instance of any type:
If any of the types in the hierarchy already exist, they are left alone. This allows you to safely use
moog.mirror to patch any gaps in the type hierarchy, making sure any types that were not explicitly defined are filled in implicitly.
You may also optionally pass a
suffix as the second argument. This is helpful if you wish to define types like this:
nifty-blog-editor : blog-editor : pieces-editor
nifty-blog-manager : blog-manager : pieces-manager
That code looks like:
If you are using moog-require, the
__meta property can contain information about where your types are defined in the filesystem. You might not want to disclose that information to the web browser. To avoid that, you may filter the
var meta =chain:;_;
Before making it available to the browser as JSON for use in a
All tests passing.
instanceOf method. Given an object and a type name, this method returns true if the object is of the given type or a type that extends it.
options argument to
isDefined, which may contain an
autoloader: false property to prevent
isDefined from attempting to test whether the type can be defined by the autoloader.
0.2.4: throw the proper exception when synchronously creating a type that extends an undefined type. (Previously an exception was thrown, but it wasn't informative. It was an accidental benefit of trying to invoke a nonexistent callback.)
0.2.3: exceptions thrown for attempts to synchronously create types with asynchronous beforeConstruct/construct/afterConstruct methods now include the correct name of the type or ancestor type that requires the call to be asynchronous.
afterConstruct expects a callback, calling
create synchronously should throw an error. This is a bug fix, so no minor version bump is required.
__meta property is available in
beforeConstruct. I regard this as a bug fix as the idea was always to have this information be available as early as possible.
0.2.0: added support for
mirror, which allows browser-side type hierarchies to match those used on the server side. To add actual code for those types, take advantage of the implicit subclassing feature of
0.1.5: added support for
extendIfFirst, useful when you don't know if there is an existing definition of the type. report certain errors synchronously when creating objects synchronously.
0.1.4: allow setting
false to explicitly turn off
defaultBaseClass for a particular type. Also corrected the unit test for
defaultBaseClass (the feature worked, but the test was wrong).
0.1.3: never pass
afterConstruct. We formerly were correctly leaving it off in the async case, but passing it in the sync case.
0.1.2: Updated some documentation.
afterConstruct, another optional method which is invoked after
construct it can be sync or async. Unlike those methods it DOES NOT take the
0.1.0: bc break:
__meta is now an object with
chain is the array of subclass metadata objects as before.
name is the class name being instantiated. Also,
__meta is fully populated before any constructors are called.