Req: Generic type constraints
Monkey Forums/Monkey Beginners/Req: Generic type constraints
| ||
I dunno, just for fun let's have a discussion about 'em? Rather than enforcing the type constraints in the generic class, why not have trans enforce 'em at compile time. C# seems to have okay syntax for this. VB.NET's would look a little weirder in Monkey when using multiple constraints.'C#-style Class RefTypeContainer<T> Where T:Object 'VB-style Class RefTypeContainer<T:Object> This gets hairier with multiple constraints.
'C#-style
Class BugsAndSkugsOnly<T> Where T:{Bugs, Skugs}
'VB-style
Class BugsAndSkugsOnly<T:{Bugs, Skugs}>
...or multiple parameters.
'C#-style
Class ValueMap<K,V> Where K:{Int,Float}, V:{Int,Float}
'VB-style
Class ValueMap<K:{Int,Float}, V:{Int,Float}>
thoughts? discuss... |
| ||
| whoops, posted this in monkey beginners instead of monkey programming.... |
| ||
| You mean like this? http://monkey-x.com/Community/posts.php?topic=7885 http://monkey-x.com/Community/posts.php?topic=518 Yes, I agree that generic bounds and wildcards would be lovely. |
| ||
| I look at generic constraints in the early days of Monkey, but was put off by stack overflow questions like: Why do you use the type <E extends Comparable> in various APIs, which is not "fully generified"? Shouldn't it be <E extends Comparable<?>>, <E extends Comparable<E>> or <E extends Comparable<? super E>>? At the time, Monkey was based on Java generics, and some of the implications this had on constraints (probably) meant code had to deal with crap like <E extends Comparable<? super E>>. I still like to think of Monkey as 'easy to use', but given I had trouble getting my own head around how this stuff was supposed to work, I wasn't keen on inflicting it on others. If I'd had a bit more experience with Java generics, perhaps I would have thought differently, but I hadn't... Anyway, possibly a good thing since Monkey generics received a major overhaul and are now closer to c#'s (and closest to c++'s) which has much saner generic constraint syntax. Still, even that is somewhat limited by the way c# generics work, eg: you can specify that 'type must have a default ctor' (not a problem in Monkey!) but you can't specify that 'type must have blah(etc)' ctor. In c++/monkey, you can basically stick anything in a generic class and, if it compiles with given type params, it compiles! With java/c#, the more you allow to be 'compilable' inside a generic type, the more elaborate your generic constraint syntax must be, leading to the above sort of nastiness. But I can sort of see how generics constraints 'describe' the intended purpose of a generic type to the compiler, and I'm not totally against the idea of making some kind of generic constraint syntax at least optional - my preference probably being for something like... Class ActorList<T Extends Actor> Class SortableList<T Implements Comparable<T>> ...ie: just use a 'mini class decl' as the constraint. Although this ignores the issue of how to specify 'numeric type', 'string type' etc, which support different operators/methods than objects. But right now, it's not a priority as it doesn't allow you to do anything 'more' than you can currently do with lazy/no constraints |
   |