public T foo(TypeConstraint lhs, List rhs);Which in my estimation is pretty straightforward to implement. You've one source for the type, and the test to ensure the two arguments are the same type follows from that. I bounce ideas off a guy I know who's also working on a toy language and in his estimation this idea was largely crap. The replacement was icky and would lead to problems later, the procedural style generics were unweildy and would lead to confusion or design restrictions later.
Enh. I don't see it.
Still, I've got design #3 done now and working for basic type binding. It doesn't do straight replacement, which should allow for limited type inferring like generic methods need.
Next steps: More unit testing, Generic method type inferring, making the parsed type parameterization do stuff, and operator constraints for generics (ie. numeric supports T +(T,T); T -(T,T) etc... similar to haskell stuff)
[edit:]
The Type inferring code is written and appears to work for at least the simple cases (foo infer foo == foo and foo infer (type identical to foo only not generated via parameterization) == same)
It kinda sucks that I had to eventually implement some form of pattern matching. This is specifically the thing that I wanted to avoid with the rejected design #2 above... Maybe if I'm feeling ambitious Version 2.0 will actually use the pattern matching in some way more interesting than generic methods.
But enough of that. More unit testing, more parser linkie, more making stuff work now. Generics should allow for the operation constraints and the Type Masquerading that I'd like to research.
Maybe one of these days I'll actually do this 'get it done' stuff I keep telling myself... :/
