Context dependent types

[js-jslog]

See issue #97 for some prior discussion.

Consider a simple nested object which groups expense per hobby per person :

{
  joe: {
    skating: {time: 1000, money: 300},
    cooking: {time: 9999, money: 999}
  },
  emily: {
    running: {time: 300, money: 0}
  }
}

We can consider these as 3 separate objects (unusual key definition comes from a derivation of a solution proposed in issue #97) :

interface Expense {
    time: Number, money: Number
}
interface ExpBy_Hobby {
    String: Expense
}
interface ExpBy_Hobby_Person {
    String: ExpBy_Hobby
}

This describes the composition of the outer object for us. But we are missing some context otherwise provided by predefined key names.

The Expense object gains context for it's Number values by their well named counterpart keys. Non-predefined keys such as those seen on the ExpBy_Hobby & ExpBy_Hobby_Person objects can't provide such context.

I believe the documentation aspect of this specification would benefit greatly from the inclusion of a key definition syntax. Something like the following :

interface ExpBy_Hobby {
    (hobby : String): Expense
}
def hobby {
    desc: "The name of a hobby",
    source: {type: "database", location: "hobby.id"}
}

For objects which gain all their meaning from the data they contain rather than their specific structure, and are otherwise difficult to discern, this is an essential documentation requirement for processes which might polymorphically handle them together.

[Mouvedia]

For the ones wondering why the type is needed for the key it's because it could either be String, Number or Symbol. We could possibly default to String if it's omitted?

[maiermic]

Consider a simple nested object which groups expense per hobby per person :

{
  joe: {
    skating: {time: 1000, money: 300},
    cooking: {time: 9999, money: 999}
  },
  emily: {
    running: {time: 300, money: 0}
  }
}

To me it looks like a nested dictionary:

Dictionary[Name, Dictionary[Hobby, Expense]]

where Dictionary[Key, Value] is a generic type that describes an object with keys of type Key with values of type Value. In this case, keys joe and emily are of type Name. Their values are of type Dictionary[Hobby, Expense]. Thus, skating, cooking and running are of type Hobby. Their values are of type Expense.

@js-jslog Is this correct so far?

[js-jslog]

@maiermic - looks good. Go on.

[js-jslog]

@Mouvedia - I haven't really expressed that part very well. The main point I want to express with that key syntax is that there is a label (hobby) which is used to link to the source definition, and then an undefined key name which I can only think to represent by it's type (String) - along the lines of your suggestion in #97.

I only included the type to demonstrate that the piece to the left is the label rather than the actual key name. It was a little clumsey for me to have to resort to using an incomplete proposal from #97.

[maiermic]

So far we neither defined Name nor Hobby. As far as I can tell, both should be of type String, right? In that case, we could use type aliases:

/// The username of a person form the database ...
interface Name: String

/// The hobby of a person form the database ...
interface Hobby: String

interface Expense {
    time: Number, money: Number
}

interface ExpBy_Hobby: Dictionary[Hobby, Expense]

interface ExpBy_Hobby_Person: Dictionary[Name, ExpBy_Hobby]

@js-jslog Does this satisfy your documentation purposes?

[Mouvedia]

Disclaimer: we currently don't have anything like Dictionary[] in rtype.

[js-jslog]

This proposition satisfies the main problem posed - that we need a way to mainingfully label the non-predefined keys proposed in #97.
The information regarding the source database is probaly too much information and will tie us to an implementation of data store.

I like this solution.

Your proposal of using Dictionary syntax is interesting as it potentially solves the problem raised with un-predefined keys of unknown quantity very eligantly.

I believe the single example given above would satisfy all of my requirements from #97 & #98.

Any thoughts on it's feasibility?

[js-jslog]

I should never have coined the term non-predefined..

If we were to accept a Dictionary definition then presumably the term dictionary key would make explicit that we don't yet know any of the key names, we don't know how many of them there may be, & they may change throughout the objects life, correct?

[maiermic]

Yes, that is correct. However, we can check if a key exists.

Given

myDict: Dictionary[String, Number]

we can access an element without checking it's existent

var uncheckedValue = myDict['myKey'];

but in that case we don't know if the key and with that the value exists. Thus, uncheckedValue is of type Number?. We can check if a key exists using hasOwnProperty

if (myDict.hasOwnProperty('myKey')) {
  var value = myDict.myKey; // we know that value is of type Number
  // ...
}

or if a value exists

if (myDict.myKey) {
  var value = myDict.myKey; // we know that value is of type Number
  // ...
}

[js-jslog]

I think my unbroken sentence in my previous comment my have caused you to misunderstand my point. I was just suggesting that an upshot of this solution is that non-predefined key (which is a very ugly term) would be replaceable by dictionary key (which is much nicer).

It expresses that the keys will be unknown in name and number until runtime & even then they will not be staticly defined. Because that is the very nature of a key in a dictionary.

[Raynos]

@maiermic

That breaks loops;

for (var k in myDict) {
  doSomething(myDict[k]); // type error: expected Number got Number?
}

It should be upto an application author to decide whether he wants a "safe dictionary" or "convenient loopable dictionary"; aka Dictionary[String, Number?] vs Dictionary[String, Number]

Alternatively the type checker has to implement bounds checking and support loops...

var keys = Object.keys(myDict); // keys != String[]; keys = KeysOf<myDict>
for (var i = 0; i < keys.length; i++) {
  myDict[keys[i]]; // Number; not Number?
}