That's basically what I'm usually complaining about. One syntax for all, exporting to a language of choice using the right converter. So you benefit from a more consistent, non-confusing syntax and destinations languages performance (of course depending on how the converter does it). And well, designing it gives me also an insight to OOP and language design problems in general. One design floating in my head was to have declaration/definition-less programming. Instead of making declarations before you use a class or object, you could write random function names and it runtime-check for it's existence, and link name and declaration on demand as you go. It'd be like having a pool of identifiers you could branch into more identifiers, ultimately leading some kind of randomly accessed chaos lists. The only way the find, for example, a method of a class would be to use a class identifier and search for it inside the pool. Once you found it, it would be linked to the name you used via runtime. I thought about a longer while and came to the fact that you'd need a huge hash table to look if the identifier was already linked. An identifier would consist of checksums of their names you used in the code. And that also means that you'd need identify a single class by using all it's superior scope identifiers. This way you can guarantee that it's possible to identify even completely new classes on demand and so on.
This brings some advantages and some disadvantages. The advantag is that you can have totally random objects with totally random classes. You could probably even generate classes on the fly and search for matching functions using parameter analysis and so on. So no more loss due to definition changes. It'd be like a search engine - maybe add tags, too, and it's possible to find a lot of different things. The first disadvantage coming to my mind is that it'd require to check EVERY member or class access using the hash table. Hash calculation and searching can be costly, especially when a lot of types share a single hash entry. And if the identifier wasn't found yet (happening EVERY first time access) it would also search through all branches coming from the superior identifier. That's quite a heavy overhead, even if you look for already know identifier before the real program starts. And the other big disadvantage is type safety and debugging. You can't just check for non-existing members during compilation since every member set is unknown/expandable. And type safety? Well, forget that. Not during compilation, that only works during execution. Of course would it be possible do to some dry checks during compilation, but that doesn't as you can add everything anytime. Ok, hm... with some special keywords it'd be possible mark a class as fixed. That could integrate nicely into my current language concept! Yes, that's it. Well, I guess I'd need a bytecode interpreter for that... However, the export to other languages could still work as I can simply disable export if specific language features where used. Good idea! Yes, I think that's the "glorious way to go" for me.