Splash

Design Ideas Archive

This is a rough collection of ideas from the very early days of Splash circa 2006-2007. Most of this page is out of date

Something new. We don't want to just copy Windows/Mac/Linux do we?
More secure. With normal files, applications must be able to access/change any file. Objects can only edit the data within them.
More versatile. Say there is a "person" object for storing info about people (an address book). That could contain a "text" object (name), an "email address" object, an "address object", a "picture object", and so on. These could be accessed individually by other objects, like an "email message" object.
Gives the data some structure so the computer can understand it. Imagine a search "type=email, to=Bill Gates, Size>100kb, has-attachment=true"
May be easier to implement. We don't need to mess around with making new file systems.
Creates one unified data space. All data, whether on your computer, a disk, or any machine on the Internet, it is accessible in one name space.
Opens up some interesting possibilities for the graphical interface. How about a 3D bubble that is your user object, containing your objects. Outside that would be a computer object, containing objects for other users and for CD drives etc. Beyond that would be a local network bubble, then an Internet bubble.
It could still be compatible with existing files. Python file objects could hold files. There could be some kind of "application" object that would be capable of running Linux (maybe windows) applications to edit those files.

Transaction Conflicts occur when objects are modified in separate transactions simultaneously
No way to prevent; you would have to:
You can't know from the start which objects are going to be accessed
Lock all objects globally
Copy Snapshot of all data on all computers
Would be resolvable
Simply raise exception when an object is modified in a committed transaction.
- Session could handle it by prompting to restart operation
wouldn't realistically happen often
Sub-objects would be committed with their master objects, so on-disk/ in-memory would always be consistent

Prevents competition between different types that do the same thing
- You could imagine a large number of incompatible Text (or other) types that are written by separate authors if the builtin type is missing something
Built-in types need to be able to have added methods
- Just create an action that does whatever you want
Would allow unit types like "5 meters" or "30 seconds"
Adds UI possibilities: highlight an address, be able to "add map"
- See (http://humanized.com)[Humanized Enso]

How do actions interact with the underlying data of the type?
- Actions wouldn't be specific to a given type
- Multiple classes (one for each original type) would have to appear as one

It would be string.as(Address).getDirections().
A conversion mapping attached to the source class, destination class, and possibly the session would provide conversion functions
Does not change the Splash VM
There would have to be a distinction between conversion and viewing as a type. If you change the city field of an Address object, does the original string change? In some cases, this could be useful: Code, GUI Objects
How would it be handled in the GUI? Example: code objects must be converted to the user's preferred syntax. The GUI must be smart enough to pass the correct type to the //as// method.
Could solve a completely separate problem in a more generic way -- replace asNumber, asString, etc.

Objects like code would look in the session for settings
Additional methods could be added through a session mapping searched by the Object doesNotUnderstand (or equivalent) method
- Would decrease encapsulation - Would the methods be treated like regular methods or only be allowed to use the public interfaces?