On Mar 8, 2009, at 18:53, Rich Hickey wrote: > I know people usually think of collections when they see vector/map/ > set, and they think classes and types define something else. However, > the vast majority of class and type instances in various languages are > actually maps, and what the class/type defines is a specification of > what should be in the map. Many of the languages don't expose the > instances as maps as such and in failing to do so greatly deprive the > users of the language from writing generic interoperable code.
My own experience is mostly with Python. Python objects are indeed essentially maps (Python calls them dictionaries). But even though it is easy to obtain the map equivalent of any object (object.__dict__), I hardly see this being done. Python programmers tend to use maps and objects in very different ways, and that includes experienced programmers who are very well aware that objects are just maps plus a type tag plus a set of methods. One reason why generic everything-is-a-map code is not very common is that the majority of object definitions include specific constraints on the maps, most of them of the form "the map must have a key :x whose value is an integer". The object's methods don't make sense for maps that don't satisfy the constraints, and most generic map operations don't make sense on most objects because they are unaware of the constraints and in particular don't satisfy them in their return values. The one area where I have seen uses of object.__dict__ is low-level data massaging protocols, like serialization or storage in databases. And that is indeed a good reason to use just a few fundamental data structures to represent everything. > Finally we have contrib.types, an algebraic data type system where > constructors generate vectors of unnamed components as instances. > Again, unnamed positional components are an onion of some algebraic > data type systems, there's no need to repeat that. Positional arguments do have their uses. In particular when there is only one argument, it would be an unnecessary pain to have to name it. On the other hand, I do see your point of having a uniform internal representation in the form of maps. > I'd very much like to see these libraries be interoperable, e.g. to > store ADTs in a database or query them with Datalog, and I know that > would be possible if they were all using maps consistently. One problem I see with storing ADTs (or anything with a type tag) in a database is that the metadata and thus the type tag would be lost after a storage-retrieval cycle. Konrad. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
