Ashy

> I guess it's this way by design. Quote from README: > > ``` > The syntax and many semantics are most directly derived from C#, while attempting to retain...

Interesting ideas, I could be seen as bias since I am a long term programmer of Rust and C#, and there is a lot of concepts from other languages we...

Suffixes should definitely be a feature indeed, not just for this use case but also for potentially allowing u64's explictly for use cases such as ids and such without being...

Although This seems like a valid solution to the issue. I would prefer something like this: Potentially Add a ability to either have a custom getter/setter handler which takes the...

> I do like the dynamic type creation idea better than our previous discussion. So returning a dynamic type like this would just return a **rune::runetime::Object** of the rune struct....

I will add as a side note (not the original point of the idea) but I spend a lot of time in game development and the rust game engine I...

I can see the purpose for this due to potentially requiring the full 64 bits. the work around for this however is just having a wrapper type, its bit uglier...

I actually agree with this; but only for the fact that `Objects` can already access their fields both via [name] and .name, overall this being a option on the `INDEX_GET`/`INDEX_SET`...

I think the issue is that this example below doesn't work like it does in Lua which is usually done in Lua for more complex runtime generated "static" type behaviour...

> Ah, right. So `GET` only works for specific fields. It would be plausible to add support though so that it can work as a regular instance fn, like so:...