Gabriel Sechan wrote: > ---------------------------------------- > >> Date: Mon, 7 Jan 2008 01:37:42 -0800 >> From: [EMAIL PROTECTED] >> To: [email protected] >> Subject: Re: Introducing Cobra >> >> On Mon, Jan 07, 2008 at 03:26:04AM -0600, Gabriel Sechan wrote: >> >> >>> You can't get rid of types, they're inherent in the universe- all data >>> has a type. All you can do is not tell me wht it is. >>> >> What about a function to manipulate a list? The code implementing the list >> does't care what specifically the type of the list is, just that the list >> entirely has objects of the same type. >> > > Then the type is list. Did you read the part of my argument where I > differentiated between types (or roles) and language types? It still has a > type/role, even if the type/role covers a set of language types. > If it was a type, then you'd have to decide if you were manipulating a singly linked list, an xor list, a doubly linked list, a skip list, a vector, a b-tree, etc. All of which is kind of tedious and besides the point if all you want to do is know that you need to assign this group as the list of people with access to account# 47. In that case, the type of the list is a distraction from the algorithm. More often, you have situations where thinking about what the type should be causes you to impose types that aren't really proxies for a role, and so you end up with less flexible code.
The canonical example in Smalltalk is the all too simple and generic case of a "bank account". You need to have "money" in your bank account, but it isn't entirely clear what the type of that money should be. You could actually make a "money" type, but then, until you have fully explored the system and its goals (which of course, change over time anyway), you don't really know what the money type should look like and what its capabilities should be. Is it floating point, fixed point, arbitrary precision, or complex? Does it support notions of currencies? Is their a temporal or geographical dimension to it ($40 at 4pm in New York at a certain day in 1929 isn't the same as the same money at a different time or place)? An economist might want to attach other odd properties to it like velocity. The federal reserver or a collector might care about where the money was minted and how. Ultimately, it's a whole lot of complexity that you don't need to deal with right now. For the most part you just need a "role" called money, because that's what this code sees, and that money isn't defined at all by how the data is structured internally, but rather the specific set of operations that you need to perform on it (which is mostly add, subtract, and compound interest). So, you just call the variable "someMoney" and the rest of it solves itself later. >> This is the problem that type polymorphism, or generics solve. (Templates >> try to solve it, but don't.) >> >> > Templates solve a subset of it. There's basicly 4 types of polymorphism. > Templates solve one. Inheretence another. C++ doesn't support the other > two. Thats by design. I have my issues with template syntax and a few > features, but lets be fair to them. > Oh, it's all about how much you want to abuse your templates. I've got three main types of polymorphism in mind: 1) Parametric 2) Subtyping 3) Ad-hoc #2 is basically done with virtual functions. #3 can be done with templates #1 can be done with templates Now, there are specific kinds of parametric polymorphism that are hard to do with templates, but you'd be amazed at all the horribly things you can do to get a close approximation. True rank-n polymorphism isn't achievable, nor is return type polymorphism, but you can get close enough that people will mostly focus on the horrid things you are doing to the language, rather than whether it is really "purely correct". ;-) --Chris -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
