> I'm having a hard time seeing an operational distinction between this > description and "wrapping an int in an obj conforming to the obj-type called > Number",
The 'wrapping' is done implicitly and transparently, and the compiler knows about it, and can thus optimize trivial things like, 'x == 0', if int is an instance of class 'Comparable', into direct calls to the int compare function, rather than creating two objects wrapping ints and looking up the compare operation in their vtables at runtime. This will allow things to be generalized without having to pay for the generality when we don't need it. As for terminology, using a new name (typeclasses) for something that's new (they are simply a different thing from Java/C++/etc classes) is necessary to prevent confusion. In the nineties, I'm sure some people derided objects as elitist. Right now, it's not hard to find people who consider functional programming ivory-tower nonsense. Progress, by being different from the old thing, is always going to take some getting used to. That being said, I have no intention of dragging functors, monoids, or other category-theory mumbo-jumbo into Rust. When possible, I agree we should stick to widely-known terminology. 'Interfaces' would have been just as good a word as 'typeclasses'. But they have been invented and popularized as 'typeclasses', so that's probably the best word to use for them now. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
