Subject: Re: garnet performance issues From: Erik Naggum <erik@naggum.no> Date: 1999/02/13 Newsgroups: comp.lang.lisp Message-ID: <3127866695326571@naggum.no> * Robert Monfera <monfera@fisec.com> | Haven't you forgotten to attach a smiley at the end of your sentence? no. | If not, what have you meant by it? To me, a parameterized type would be | something like "vector of integers" or "list of bank transaction objects" | where you parameterize LIST or VECTOR with your choice of element type. this entire issue is a joke on the explicit typing crowd. by refusing to understand that lists and vectors and other generic collections shouldn't _have_ to be specialized on the type, they _invent_ a stupid need that smart people don't have. the whole parameterized type nonsense is a testament to bad language design. it is completely devoid of meaning. incidentally, (make-array <dimensions> :element-type <type>) is your parameterized type if you didn't like my COERCE example, which I use to show these explicit typing doofuses who drop type information at runtime what they _really_ wanted, but didn't know how to ask for. imagine a simple function that accepts a type _name_ as argument and tries its best to convert an object into that type. it's template hell in C++. the name of its types are _gone_ at runtime, for starters. if you want a list of bank transaction objects, just don't put anything else on it. how hard can it be? I fail to see the need to construct a bogus language construct just to make that _harder_. if you want a typed container, define a class that has a type specifier and a sequence or whatever you want to hold them, and provide general functions to add things to it after having checked the type. the problem is that this stuff is so seldom _needed_ in a language that remembers the types of its objects apart from whatever variable used to hold them. | You can specialize methods on STRING, but not with something you create | with DEFTYPE. if you're talking about CLOS methods, you're being disingenious. CLOS was designed to dispatch on classes, not types. if you don't like that, nothing whatsoever stops you from running down a TYPECASE or making a more general mechanism. yes, you have to roll your own. that's true for just about everything people want. "I do not want what I haven't got" does not apply to programmers. incidentally, PPRINT-DISPATCH has a nice type-dispatching system that does a lot more than CLOS dispatch does. just because something is a good thing to do when you regularly shoot yourself in the foot, doesn't mean it's a good thing to do if you can avoid shooting yourself in the foot. enough comparisons with C++. I get sick to my stomach thinking about the talent wasted in inventing ways that braindamaged language can hurt less. #:Erik -- Y2K conversion simplified: Januark, Februark, March, April, Mak, June, Julk, August, September, October, November, December.