The Sourcerer

Got Style?

There's a new JavaScript library from Google on the block. So, I'm of course out to absorb the good bits for Chiron. I've got to wonder some times whether people have started to use ideas from my code.

Compare this bit from Google's JavaScript library with this one in Chiron.

I don't hear much about people using Chiron. Could this be a sign that people have been reading it and absorbing the good bits? There are other parallels. For example, some of the function names and file names match up with Chiron too, like base.js and inherits (instead of Doug Crockford's recommended term, begets).

De Schpugeti

You've heard of syntactic sugar. After a syntax and vocabulary provides all of the normal forms necessary to express all of the programs possible in a language, yummy shortcuts bridge the gap between expressiveness and usability. For example, c++ is a delicious variation of (temp = c, c = c + 1, temp).

You've also heard of CRUD, an acronym for the normal forms for a data programming interface (databases, data structures). If you design an interface library for data and fail to cover all of these bases, you deserve what's coming to you — and I can't promise that it won't involve a big hole in the ground and Hello Kitty.

CRUD stands for create, read, update, and delete. Those functions encompass all of the necessary data interactions; however, they are not sufficient. While CRUD may provide all the nutrients, vitamins, and minerals your data API might need, it certainly won't taste good without sugar.

Enter: Chiron.

del, set, cut, has, put, get. De Schpugeti. All of these names are three letters long, should be familiar by their names, and are sufficient in addition to necessary. These methods are the interface of Chiron's Dict, for manipulating item data: data that have keys and corresponding values. They are also implemented in a consistent manner by List presuming that indices are like keys.

del

Deletes an item for a key.
Returns the mutated collection.
For ordered collections, accepts a beginning key and an ending key, deleting all items in that range of keys excluding the ending key.
Implemented in terms of remove.

set

Adds or overwrites an item for a key.
Returns the mutated collection.
Implemented in terms of insert.

cut

Deletes an item for a key.
Throws a key error of no item has that key.
Returns the corresponding value.
Implemented in terms of get and del.

has

Returns whether key is among items.
Implemented in terms of has.

put

Adds an item for a key.
Throws a key error if there is already an item with that key. returns the mutated collection.
In an ordered collection, reserves the right to change the keys of some other items to make room for the new item.
Implemented in terms of set and has.

get

Returns a value for the given key.
Throws a key error if there is no value for the given key.
Implemented in terms of retrieve and has.

Also, Lists, Sets, and, by extension, Dicts have functions for managing collections of values that do not have keys. Dict is a Set of items instead of mere values that are compared and hashed on their key.

has

Returns whether a collection contains a particular value.

insert

Adds or overwrites a value.
Returns the mutated collection.
Defaults to an implementation in terms of find and set.

retrieve

Returns the contained value that is naturally equivalent to a given value.
Throws a value error if none exists.
Defaults to an implementation in terms of find and get.

remove

Removes a value.
Throws a value error if the value isn't in the collection.
Returns the mutated collection.
Defaults to an implementation in terms of find and del.

discard

Removes a value if it exists.
Returns the mutated collection.
Implemented in terms of has and remove.

find

Returns the key for a given value.
Accepts an optional equivalence relation to override the default of eq.

Now accepting ideas for a good mnemonic.

The fun trick is that List, Dict, and Set implement all of these functions. While it may be more appropriate to use one collection type for one kind of data or one algorithm, you can use any of these types interchangeably.

Integrating Simile

Not to name names, but I've been working on integrating code from Simile from MIT into Chiron. Refactoring an existing JavaScript project highlights all the things you get for free in Chiron.

Simile has it's own XHR engine, DOM event wrappers, DOM layout and style functions, PNG transparency solution, and a SortedArray type that provides binary search functions. Here are some of my observations.

• Simile's layout getSize was better than mine. I will rectify this.
• Not having a module system makes us reinvent the wheel: frequently.
• It's hard to write a good XHR engine. There are a lot of XHR modules out there, most of them have some issue or another: missing browser, doesn't report OK status on local files, doesn't unify browser caching inconsistencies, doesn't support timeouts, doesn't expose XML (the X in AJAX) in IE, or so on. If you're going to make a new one, you should use these as references and do some serious research, development, and testing. Otherwise, you should copy or use the best of them (jQuery, in my opinion). Also, it needs to support asynchronous (the A in AJAX) requests, and you need to use them as often as possible.
• Not having a solid, modular library makes us lazy. The inconvenience of name-spacing makes us lazy. This causes us to write sloppy code. For example, we should always use an enquote function when we're string interpolating HTML attributes and an inoculate function when we're interpolating HTML, or we should use DOM functions or a DOM wrapper API to generate our HTML.
• As I integrate code from other libraries, a pattern emerges. In my first pass, I collapse the name-spaces. Every module is a name-space, so all the manual creating of hierarchies like Simile.DOM (Simile = {} presumed, then Simile.DOM = {}, then endless repetition of Simile.DOM to augment or use its contents) is unnecessary and undesirable.

Referencing URL's of resources, like other scripts and images, relative to the URL of the script you're currently in, is hard. Starting from scratch, this usually means you're going to have a global URL constant. This means domain-coupling. Maybe you make the URL relative to the root. This means domain-coupling. Maybe you provide it as a configuration variable. This means site-coupling. Maybe you scrape the script tags on the page for the URL of your script then resolve the URL relative to your own URL. This means you're going to write a lot of slow code for what you perceive to be little value. In Chiron, you can get a function called resolve from http.js that resolves a URL relative to a base URL. Chiron also provides your modules with a moduleUrl variable that is the URL of the script you're in. resolve also implicitly uses this variable as your base URL if you don't provide a second argument(include('http.js'); resolve('images/blah.gif')).

Chiron grabs the script tag href of modules.js and removes the script object from the DOM (so other scripts can't sniff it) exactly once, since it needs that URL to resolve other module URL's. From there, Chiron keeps track of where all of your modules are relative to it and provides that information to each module.

• About SortedArray:
• A collection type should create an empty instance if you pass no arguments in.
• A collection type should populate itself from the values of another collection if you pass one in as its first argument. This should always be the first argument, even if you frequently create empty collections with overrides on later arguments. Force your user to pass in a null or undefined.
• Try to accept null and undefined as equivalent unless the distinction is meaningful.
• Try to distinguish null and undefined from 0 in all meaningful cases.
• Invariants like "sorted" are a promise. Guarantee your invariants across all function calls, including construction. If this means an unacceptable performance degradation, permit the user to suppress whatever code you need to verify the invariant if they are willing to provide treated data.
• If there is a reasonable default, it should always be implicit. I should not have to explicitly send the global compare function into a SortedArray if I want a SortedArray of types supported by compare.
• Not having a system of base types makes for noisy API's where names from different organizations have different meanings. For example, find functions should always accept the same kinds of arguments and return the same kinds of values. Simile's name choices are very close to mine, to the effect that they could almost be used as partially implemented duck types for mine, but some of the names would have to be realigned. find in Simile accepts a comparator and returns an acceptable index to insert or remove a particular element. find in Chiron returns an index or key at which an item can be inserted or removed, and guarantees that it will be the first occurrence of a given value (not a comparator). It was very easy to refactor SortedArray to subscribe to the strict model. Also, removeAll needed to be clear, length and getCount both needed to be getLength, getIterator needed to be iter, next needed to throw StopIteration once in a while, among others.

I'm looking forward to having a semblance of Simile Timeplot and Timechart in the Chiron family.

Polymorphic repr

I'm not about to debate whether debugging is a valuable exercise in JavaScript, nor whether introspection or reflection tools are useful, nor whether they would be especially helpful in a dynamic language. Ruby has inspect. Python has repr. The Chiron JavaScript library has repr too.

Notionally, repr is the inverse of eval for a reasonable subset of JavaScript. There are a lot of object hierarchies that cannot be reconstructed from a repr serialization, but as a debugging tool, repr is indispensable.

repr is a polymorphic function you can import from base.js. If you pass repr an object that implements a repr member function, repr will defer to your overridable repr. Otherwise, repr returns reasonable defaults for other types. For example, repr provides defaults for Array, Object, String, Number, Boolean, and Date. repr also recursively represents members of arrays and objects, but provides circular reference protection by tracking visited objects in a memo Set.

Chiron's debugger uses repr to convert the value of an expression on the command line to a human-readable string.

j$ 1
1
j$ repr(1)
"1"
j$ "hi"
"hi"
j$ repr("hi")
"\"hi\""
j$ true
true
j$ {a: 10}
{"a": 10}
j$ [1, 2, 3]
[1, 2, 3]
j$ [{a: 10}]
[{"a": 10}]
j$ var a = {}; a.a = a; a
{"a": <cycle>}
j$ type()()
<instance run.html#0 0>
j$ type({'repr': function () {return "x"}})()
x

modules.js

We've posted modulesjs.com this evening to proliferate what could be the most important piece of code I've ever written, modules.js. This JavaScript is the core of my Chiron JavaScript library project for the Tale game user interface, but could stand alone as the core of any number of JavaScript library projects. Every popular JavaScript library could benefit from a module system that handles dependencies and isolates name spaces like Python or Ruby. Read the tutorial and look over the code. Find me on an instant messenger or my face in the big blue box or send me an email and tell me what you think.

Thanks go out to Ryan Witt for managing the server and domain, my sister Kathleen Kowal for the graphic design, Ryan Paul, Ryan Ernst, and Mike Stone for proofreading and particularly to Ryan Paul for letting me expound at him nigh daily for the last decade.