Water brings to the table capabilities that are not simple “add ons” to an existing language. It contains concepts not present in today’s popular languages.
Yet it doesn’t start off by throwing today’s web author in cold water either.
– Minimal differences between markup, data, and code. Seamless integration between HTML and code.
– Minimal differences between classes and instances. Prototype object systems have just one kind of object.
No need to learn separate operations for classes and instances since there’s no distinction between a class and an instance.
An object can be used “as an instance”, and/or it can be “subclassed” with the new object inheriting the desired characteristics of its parent(s) while other characteristics are modified to differentiate the new object from its parent(s).
The language “Self”, invented at Sun but never made into a product, had a simple and elegant prototype-based object system.
Self’s object system differs from Water in that it was only single-inheritance and had a “copy down” semantics for inherited values rather than the “dynamic look-up” mechanism of Water.
Water’s multiple-inheritance is easy to avoid should you find that it adds too much conceptual hair. The dynamic lookup of Water makes object creation faster and uses less memory than “copy-down”.
It also preserves locality of reference for shared data which may have additional speed advantages for hardware with limited caching.
But if “copy-down” is desired, the “init” function for object creation of a given parent object can choose to copy down desired fields.
If this proves to be important, Water could provide higher level support to make this easy. Hence, Water is a superset of Self in these regards.
– Minimal difference between “instance variables” and “methods”. Each are stored as values of fields in an object.
You can get the value of an instance variable or a method by just getting the value of a named field. Methods are implemented by objects just like everything else in the language.
To CALL a method, you use the function calling syntax which looks like using an HTML tag.
– Minimal differences between a function call and object creation. The tag name refers to the parent object. The parameters after the tag name serve as either function arguments or field initializers depending on whether the value of the tag is a method or not.
– Minimal differences between aggregate data types. Objects, vectors and hash tables are all represented by the same data structure.
An object is a set of fields whose keys can be any object [interned strings, numbers, other objects]. When you’re treating an object as a vector, a looping mechanism permits looping over all fields whose keys are integers.
A “length” field makes finding out the size of the vector quick as well as facilitating “adding an element” to the end of the vector.
– No differences between the object system and the type system. For example, “integer” can be thought of as a “type” but its really just another object in the object tree that happens to be the parent object of all integers.
You can reference all objects used as types via the path syntax, just like you can reference all fields of objects. In fact, since any object can become a parent, any object can effectively be a type.
– Minimal differences between the init method to create new objects and normal methods. An init method can, in fact, return any type of object and should declare the returned type of object.
– Minimal [but very significant] differences between local variables, and object fields, for creating, setting and referencing.
– Minimal differences between a field and an annotation to that field. Water provides a way to add information ABOUT a field. Say you have a field named “color” in an object named “car”.
You might want to add a comment about the field such as “all colors besides black and white cost extra” or declare that the type of the field must be an integer.
Annotations are the mechanism that Water uses to associate information about a field with that field. Annotations of a field “foo” are indicated by another field with a naming convention of “foo@annotation-name”.
A looping mechanism makes it easy to find all annotations of a given field or to ignore all annotations of an object when you want to loop through an object’s field values.
– Water provides an easy way for a programmer to specify the “evaluation kind” of each parameter in a method definition.
This controls how each argument in a call to the method is interpreted.
- Code Evaluation: Can be treated as code and evaluated by default.
- Expression Parsing: Can be treated as an expression to be parsed but not evaluated. This is particularly useful for “delayed evaluation” scenarios where a method takes code as an argument and can evaluate it when it chooses.
- Source Code String: Can be treated as the string of its source code without being parsed.
- Hypertext: Treats text within angle brackets as code to evaluate and other text as strings. This is especially convenient for implementing HTML tags as Water objects or method calls.
– Water’s object system permits the parent of an object to be changed at runtime. Not a common situation, but sure makes it easy for a parent to “adopt” a child.
– In HTML you usually use keywords to specify each attribute. XML requires the use of keywords. In Java and Javascript you can’t use keywords to specify any argument.
Water permits you to use keywords when you want to be more explicit or pass arguments “out of order” and pass arguments by position (without keywords) when you want to be more concise.
There is no extra overhead for declaring keywords when defining a method, they are simply the parameter’s name.
– “Active Values” on object fields facilitate simple constraints and, along with other dynamic features, help to implement spec changes after most of the implementation is done by permitting field references and setters to turn into method calls without changing the referencing and setting code at all.
– Water is especially easy to write tools for due to its extensive introspection capabilities, evaluation kinds, elegant object system, uniform syntax, ultra-dynamic behavior and small size.
