WordsWorkArtPhotos

Universal Types

IdeasProgramming

These types generally take the form of persistent trees. This allows people to modify them as they wish and recover from any unexpected changes. I have in mind that these objects will be stored in a collections framework that allows for common operations over most data structures.

Building Blocks

I think that every item can be composed of these core primitives. If you think otherwise send me an email with an example that breaks the system.

  • text
  • locations
  • audio
  • video
  • messages
  • number
  • time
  • transactions

This primitives along with an alias system allow for any type to be created.

Common Functions

Because these types are consistent, and supported throughout the system, you can apply common filters, sorts, or apply functions to every item in the collection.

For example, I would like to find a contact of mine, but I've forgotten their name. I know I added them recently, and that they didn't give me their email. I ought to filter by contacts who do not have an email, then sort by how recently I added them. I have about 600 contacts in my address book, and neither of these operations would take much time, even if they are not heavily optimized.

Imagine the power if you could do that for all these data types. You could find the closest x just by getting a list of x, then because they have a location, you can find out their distance from your current location. The coffee shop use case has been polished, and for coffee shops its super easy. What if you're looking on someones blog for good gluten free restaurants in Sacramento. You think this person knows what they're talking about, and you'd like to know how far away all of them are.

Well, right now you have to type them all in to google maps, or have knowledge of the area to figure out how far away they are. This is obviously sub optimal. If you have a list of restaurants, even just their names and a general geographical location, you ought to be able to find the distance from you to them without having to code something to do it, or type in 10 address to google, and compare across multiple tabs.

This is basically an Entity Component Model applied to general programming.

Items

Each item has an identifier and a series of key:val pairs. Each of these keys indicates that the item has a attribute of that type. If the item has multiple values of the same type then they just form an array under the specified key. key:[val1, val2]

Representing Items

Suppose you have a news article:

article1209{
  author: Devin McGloin
  title: Universal Types
  date: 2016-01-29
  text: These types generally take the form of persistent trees...
  source: http://blog.devinmcgloin.com/universal-types
}

All articles are based off this template:

article{
  author:
  title:
  date:
  text:
  source:
}

Some of these are not in list of primitives above. author is an alias for person. An author looks like this:

author{
  alias: person
}
person{
  first-name:
  middle-name:
  last-name:
  email:
  phoneNumber:
  address:
  employer:
  hometown:
}

Interfaces

We need a mechanism to ensure that each alias is what it says it is. This is only an issue for aliased types, and not compositions. If the alias is not a subset it does not need to be verified, as all members of text can be aliased as strings. However, a url would be aliased from text, but is actually a subset of text.

For text the answer is somewhat simple, have regex matching patterns that confirm the identity of the alias.

url{
  alias: text
  matches: #\b(([\w-]+://?|www[.])[^\s()<>]+(?:\([\w\d]+\)|([^[:punct:]\s]|/)))#iS
}

I don't see a use case for aliasing location for example, to a smaller subset that doesn't result in a new composite type. If you do, please get in touch!

Algebraic Types

The source item in the article template is a rather vague term, in fact this is intentional, as we would like to define a generic article, rather than have a web-article with a url, and a journal-article with a journal edition. We'd like to treat those two things as part of the same greater idea.

A good solution to this problem is introducing algebraic datatypes. Composition already covers the and use case, so what we're really look for is either. The source is either a url, isbn or a journal. Either does not allow for both a url and an ISBN.

source{
  either: [url, isbn, journal]
}

More to do

Obviously, there is a lot more do do around these ideas. If you find them interesting I'd love to talk with you!