But I've spent my commutes pondering what I want, how to implement it, and if any of the ideas are self-contradictory or otherwise problematic. I've worked through enough of the ideas to start jotting down some of the requirements into my notebook and look into getting some code into the editor.
The original motivation was from some of the threads discussing composition and program design in Game Programming. The entire process of taking disparate parts of code and gluing them together is harder than it should be. Since that is increasingly what developers actually do, it should be easier.
So there are three main points where I think improvements can be made.
1. Inheritance sucks.
When the conceptual goal for something is to take module A,B,C, and maybe D and glue them into some nice object where they all work together, having single inheritance is conceptually askew from that. Having to translate from one thinking to another is a bit of work and can lead to errors. Multiple inheritance has plenty of its own problems which only adds to the work the programmer has to do.
Loose typing circumvents a bit of these problems, but introduces a number of others. I like statically typed languages, and think that the benefits of them are almost always advantageous for non-trivial applications.
So I'm going for mixin style inheritance. Allow for multiple inheritance (or at least ease the programmer work in making multiple inheritance into chained single inheritance), but mitigate the problems while still following a statically typed feel for things.
2. Functions are important
(and by extension, operators)
Using C# for a while as my hobby language has led me to kind of hate delegates. Not delegates themselves, but the shoddy implementation in .NET. A programmer will have to work with functions, and perform operations with them. Adapting a function to a different signature is one of the key 'glue' operations a programmer needs to do. Make it easy.
And heaven help you if you need to use the signature to parameterize anything...
3. Rigid Typing is... Rigid
This is sort of an extension of #1. Interfaces in C# suck. They require explicit inheritance to assign an instance to a variable (and by extension a parameter). When you're sitting there with 3+ modules, there's bound to be methods just sitting around that take interfaces (if you're lucky) as parameters. Out comes the glue and a class or two are inherited again to explicitly adapt to the interface; obfuscating what's going on and require a good bit of work from the programmer that isn't necessary.
Duck typing helps this greatly, but can lead to a few problems. It often just checks that the stuff that's used is in the type it's dealing with. Not so good when the module you're including changes it's signature or you swap in a new concrete class that doesn't quite use the same stuff. Or it uses type inference which obfuscates what's going on (especially when everything else is statically typed).
Especially with the mixin stuff, I want to provide psuedo-duck typing. Simply loosen the standard casting operators/implicit conversions to do the capability checking between types, rather than between usage and type as normal duck typing would do. So the function can specify Ifoo as a parameter type and the argument coming in just needs to satisfy the interface, not necessarily inherit from it.
Not that it matters too much. I still lack the CS-fu to take on such a project, let alone make it good/suitably fast. Still, it should be a learning experience for the very least what I don't know. So I'll work on it a bit as time allows. Hopefully enough to sate my whimsy so I can get it back onto useful stuff.
