Euclidic

This is just a place holder for now, but Raine and I have decided to refer to the objects which end circular definitions as Euclidics.

Lolwhut

From http://en.wikipedia.org/wiki/Axiom:

Tautologies excluded, nothing can be deduced if nothing is assumed.

The Euclidics are those axiomatic assumptions upon which the rest of the world is built.

Identified so far

Euclidic

The root object. If there is anything in common amongst all Euclidics we'll define it here.

Entity

Anything which can be the subject or object of a relationship.

There may be no reason to distinguish between Euclidic and Entity, but until we're sure we'll keep them separate. In any case we can keep the implementations and interfaces of Entities and Relationships apart this way.

Actor

source of events

Group

Wraps a collection of entities so they can be referenced as though they were a whole.

Some examples:

• composed objects such as a person composed of their body and everything they're carrying or wearing
• piles such as a heap of clothes or a stack of books
• function collections such as a shield which is also a mirror
• steps in a process
• social associations

Change

Types:

• Morph - modify a parameter or aspect
• (Dis-)Associatate - Make/break relationships
• Create/destroy - modify the fundamental class of an entity

Action

Something an Actor uses to spawn Events

Event

A change that will happen or has happened.

Behavior

Relates external code to a Euclidic.

Relation

The engine itself will also implement relations as their own data type for speed, but the Relation euclidic will wrap it and associate it with the rest of the core.

Examples:

• Wants(Actor -> Goal)
• Contains(Bag -> Item)
• Material(Club -> Wood)

Threshold

Divides a group.

Goal

Describes a scenario an Actor may pursue.

What every Euclidic has in common

Modules invoked with a parameter which is a function and an object. That parameter refers to 'dimensions', so it will be a best practice to call it 'dim':

• dim("by name") - used to pull in a dependency
• dim("engine") - like $sys in ColdMUD
• dim("core") - KINDA like $root in ColdMUD
• dim(name, version) - request a specific version

Once a dimension is loaded it also becomes a property of the injector which was used to load it. That is, dim("engine") === dim.engine. Note however that if "engine" isn't loaded already, dim.engine !== dim("engine") because the expressions are evaluated left-to-right. In any case, it is recommended that dependents store their own reference if they need one:

  @program myModule, '_init', (dim, args...) ->
    @engine = dim "engine"    , "0.0.1"
    @core   = dim "core/finch", "0.0.1"

    # more init...

FinchCore v0.1

Dimensions

Engine

Exports:

• local
• Used by loaded behaviors to extend the system
• relation
• Used by everything
• proxy
• For cross-domain hanky-panky
• behavior
• For loading (and saving!) code
• Also for registering dimensions
• Also for registering repositories of behaviors
• Default is a local file system dir treated as a node_modules location
• property
• For associating arbitrary data with locals and relations
• domain
• dimension
• same as first argument passed to modules

Not exposed:

• connection
• config

Core

Exports:

• policy
• cannon

Objects

Euclidic

• .name, .desc, .rel[ationships]

Relation

• ::instances
• ::subjects
• ::objects
• ::relate(subj, obj)
• .subject
• .object

Dimension

• .version

Behavior

• .repo
• .name
• .version
• .url
• .package
• .install