On Mar 4, 2008, at 10:27 PM, Darryl wrote: > I would argue that type parameters for collection > classes are completely unnecessary. Supposing some > collection class Set with a method add, it would be > trivial to subclass it to TypedSet. Simply have an > argument in the constructor called contentType, and > redefine add to force type checking of all items being > added, filtering out anything not matching. I don't > see why it's necessary to clutter up the syntax with > ugly Set.<int> like notation when existing > functionality can handle this sort of type constraints > with ease and elegance.
Arguments to a constructor can't be type terms, so can't be used in annotations, so can't be type-checked. You must mean manual, runtime "type" checking by typeof, instanceof, or other tests. That's not what type checking means in the context of type parameters. I suggest focusing on semantics and setting aside syntactic issues for a bit. If you just don't want optional types anywhere, then why pick on type params? /be _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
