Add ability for typealias / typedef

[iccir]

When type checking, @enum is handled as a Number. However, in the musictheory.net source base, we have non-enums that also need to be numbers (MTStaffPosition, MTKeySignature, MTMIDIValue, etc). The current solution is just use Number as the type for these ivars and method arguments. That means less-documented method signatures, however :(

We should have some kind of 'this type is also a number" directive, perhaps:

@typedef Number MTStaffPosition;

Also, since Rect/Size/Point are actually simple Arrays, we should be able to typedef those as well:

@typedef Array Rect;

A non-feature, for now, is handling complicated Typescript types:

@typedef Array<Number> Rect;

[IngwiePhoenix]

That sounds like a very nice idea! It would make reading method signatures much more distinct too. Being able to do some kind of typedef’ing also has another advantage: „What is what, actually?“. I see that a lot in C++ when typedefs are used. A common example might be

typedef vector StringVector;

But some devs are shortening type names…

typedef vector strVec_t;

In this case, one might see…

Foo::bar(strVec_t& input);

In OJ, we could potentially get the same - one should be aware of it. But actually being able to use a typedef to make an emum, or special type, that one uses, more distinct within the code or method declaration sounds like something very useful.

Am 07.11.2014 um 02:32 schrieb Ricci Adams notifications@github.com:

When type checking, @enum https://github.com/enum is handled as a Number. However, in the musictheory.net source base, we have non-enums that also need to be numbers (MTStaffPosition, MTKeySignature, MTMIDIValue, etc). The current solution is just use Number as the type for these ivars and method arguments. That means less-documented method signatures, however :(

We should have some kind of 'this type is also a number" directive, perhaps:

@typedef Number MTStaffPosition; Also, since Rect/Size/Point are actually simple Arrays, we should be able to typedef those as well:

@typedef Array Rect; A non-feature, for now, is handling complicated Typescript types:

@typedef Array Rect; — Reply to this email directly or view it on GitHub https://github.com/musictheory/oj/issues/30.

[iccir]

Note that the vector<String> case is explicitly a non-feature for now ;) I'd love to have it, but we don't know what direction typed objects are going to take in ECMAScript (there is a proposal at https://github.com/dslomov-chromium/typed-objects-es7 , there is AtScript, and there is TypeScript). There is also a small possibility of typed arrays making it into Obj-C at some point. If so, that might use a different syntax (which would be preferred for oj).

[iccir]

Regarding typed arrays, #31 covers that. The typed objects in ES7 will likely have a different syntax; however, since we need to support protocols for types (id<Protocol>), and since an oj class can never extend the native Array type, we can allow Array<Subtype> for now.

[iccir]

(Closing as this is in master)