Brian S. Julin via RT wrote: > it would be OK for there to be some tiny chance >of a collision between two WHICH.Str's as long as the actual WHICHs >do not collide.
One could make that distinction, but then the .Str of the .WHICH would not fulfill the purposes for which .WHICH is used, and would seem pretty pointless. Consider the Set class, as an example user of .WHICH. It needs something that it can easily hash and compare, and whose equality corresponds precisely to object identity. That doesn't have to be a string, but a string is a convenient format for that. So OK, if .WHICH.Str doesn't do the job then Set can go to extra effort to use the `real' non-colliding .WHICH value. In this context, a colliding .WHICH.Str is worse than useless: it's an attractive nuisance, because it'll function well enough as a .WHICH substitute to pass most test suites but then fail in real use. >So, I'd suggest the stringification of a .WHICH be of limited length, give a >few >clues about the type/value and what is in it, and above some threshold or when >anything messy is detected, elipses and a hash, and we just tell the users we >are doing >that and not to rely on that stringification for end-of-the-world scenario >things. Key question: what value does a colliding .WHICH.Str add? You seem to envision it as a human-oriented inspection mechanism. But we've aleady got more than one of those. .perl, .gist, and to a lesser extent .Str all provide some kind of representation of an object's content as a string. There is conceptual room for more than one of these, since they can take different views of what aspects of an object are important and what kind of ambiguities in the output are acceptable. But in practice there isn't enough attention paid to these to justify even the range of methods that already exist. In many respects .perl and .gist are near clones, because .gist has neither a clearly defined output format nor clearly different rules about what to represent. It would make a fair bit of sense at this point to delete the less-useful .gist. It would be crazy to go the other way, adding yet another stringification mechanism with no hard identity requirements, no defined format, and no rules about how much to represent. Even if there were some demand for yet another stringification method, .WHICH.Str would be the wrong place to put it. Half-hearted inspection is entirely contrary to the basic concept of .WHICH. If such a method is to be added, it should be a method directly on the principal object. .WHICH doesn't have to supply a string directly, or even just a string wrapped in a funny class, but the object it supplies should be concerned entirely with the precise identity of the principal object. For the .WHICH value to stringify to anything that doesn't have the same identity properties would be misleading. If you're interested in a human inspecting the .WHICH value itself, rather than inspecting the principal object, then the most important method to consider is .WHICH.perl. By the intent of .perl, this ought to produce a string that fully represents the actual .WHICH value. Ellipsis is not useful here. It would be acceptable for .WHICH.gist to provide a lossy representation, but .gist is so loosely defined that almost anything is acceptable. >there's room left open for not requiring WHICH implementation at all on value >types). >For value types, .WHICH could very well be just identity That too would break Set and anything else that needs a way to hash object identity. A .WHICH method producing a consistent type of output is useful on *all* types. > It would seem to me that implementing eqv and === candidates to work >directly on values would be faster than making up some weird WHICH value and >then >comparing those values, Sure. eqv/=== should absolutely be implemented in type-specific ways where that can be done faster than .WHICH comparison. And code comparing for object identity should use the likely-faster === in preference to comparing .WHICH values. But .WHICH still needs to be there, for users like Set that need to do more than identity comparison, and equality comparison of .WHICH values must always behave the same as ===. -zefram
