chip@ateng.ateng.com (Chip Salzenberg) (09/27/88)
According to dml@esl.UUCP (Denis Lynch): >But you missed the point. Of course linked lists are useful. They are >a separate concept of their own, and shouldn't be imbedded in you hash >table constructs. [...] The HashNode isn't the thing that >really has the "next" property, that is the responsibility of the set >or sequence. I appreciate the clarification. But I must make comment on the following: >In short, look at something like OOPS. Use a set of basic "computer >science" classes to handle lists, arrays, sets, etc., independent of >the *contents* of the collections. The whole issue of container classes is one that gets religious pretty quickly. Smalltalk devotees -- and their acolytes, the Objective C folks -- rant on about container classes that work the same no matter what they contain. Personally, I consider the whole issue a red herring. For example, the Objective C book gives the example of iterating across all objects in a collection, adding up their weights. The hidden gotcha: What guarantee is there that all objects in the collection respond correctly, or at all, to the "getWeight" message? The likely answer: "Well, I know because I put them there." In that case, you don't *really* have a heterogenous collection. To get back to the original example: Yes, perhaps I should have implemented a HashNodeCollection type to hold all the HashNodes. But I certainly would not create a huge class hierarchy with virtual functions everywhere just so I could create pseudo-heterogenous collection classes. That method may be appropriate for Smalltalk and Objective C, but it's not "the C++ way". -- Chip Salzenberg <chip@ateng.uu.net> or <uunet!ateng!chip> A T Engineering My employer may or may not agree with me. The urgent leaves no time for the important.
db@lfcs.ed.ac.uk (Dave Berry) (10/05/88)
In article <1988Sep27.103559.4881@ateng.ateng.com> chip@ateng.ateng.com (Chip Salzenberg) writes: > >The whole issue of container classes is one that gets religious pretty >quickly. Smalltalk devotees -- and their acolytes, the Objective C folks -- >rant on about container classes that work the same no matter what they >contain. Personally, I consider the whole issue a red herring. > >For example, the Objective C book gives the example of iterating across all >objects in a collection, adding up their weights. The hidden gotcha: What >guarantee is there that all objects in the collection respond correctly, or >at all, to the "getWeight" message? The likely answer: "Well, I know >because I put them there." In that case, you don't *really* have a >heterogenous collection. >-- >Chip Salzenberg <chip@ateng.uu.net> or <uunet!ateng!chip> That's where parameterised types are useful. You can create collection objects that are parametised on the type they contain. Then an iteration function on that type can be used with the collection. The combination of type parameters and subtyping mens you can define collections in library classes which can be used with a range of types, provided those types form a type hierarchy. If you want, you can use collections of just one type, as in your hashnode example. The same library class can be used for homogeneous collections or for heterogeneous collections. I don't know how Bjarne is designing the C++ parametised types, but I assume that they'll work along these lines. Dave Berry. db@lfcs.ed.ac.uk
harold@fmrco (Harold Naparst) (06/10/91)
I need to create a set of objects of class X. After the objects are in the set, I need to be able to find and change the objects. The g++ library does this extremely well with Pseudo-indexes via the seek() method. My question is: Does anyone know how to do this with NIHCL? It seems that NIHCL doesn't provide methods for finding and changes objects once they are in the container. For your info, the reason I want to use NIHCL is that I am using AT & T v.2.0, which supposedly can't compile g++ libraries. Thanks, -- Harold Naparst | (uunet!fmrco!harold) Fidelity Investments | (617)-570-2587 82 Devonshire St., #I40B | The opinions expressed herein are not those Boston, MA 02109 | of my employer.