jtoman

I think a lot of the issues raised by this issue can be solved using function instantiation as mentioned in #44. In addition, under the new solving scheme, the code...

Looking at Ruby's parse.y, it appears that alias is actually built into the parser and is not a function call (I'm surprised too...). I don't know how practical it is...

I have confirmed that alias is not a method call: ``` ruby class Foo def self.alias(foo,bar) p foo,bar end def foo end alias :bar :foo end ``` The self.alias method...

Looking at the old parser, it appears that alias was a keyword. Is there a reason to use type_alias over plain alias?

I think that makes more sense. I would add the rtc_ prefix to it so we completely avoid confusion with the alias method. Do you think the type abbreviations mentioned...

Well, we'll still need to invoke the parser, something will have to parse the type that someone writes, it's just a difference between ``` ruby rtc_type :my_type,":foo or :bar" #...

I think we're confusing the two issues. Type abbreviations, as mentioned in the ticket, saves people from having to write long complicated types over and over again. Type aliasing allows...

No, the RTC_DISABLE feature has not been ported to affect rtc_annotate, rtc_instantiate, and rtc_cast.

Optionally, we should support #12 (for better annotations). In order for these standard library annotations to be used effectively, we should also implement #9.

self annotations on modules currently work. In addition it'd be nice if we could use modules as names in the grammar, so that a method would accept only objects whose...