On Tue, Mar 25, 2008 at 4:49 AM, Attila Szegedi <[EMAIL PROTECTED]> wrote: > > And pretty soon, I hit an obvious design problem (which is okay, > really - this is still an exercise in exploring the right approach). > Namely, lots of languages actually have two namespaces when it comes > to accessing data belonging to an object. I'll refer to one of them as > "attributes" (as that's what they're called in both Ruby and Python) > and the other are "items", which are elements of some container > object. All objects have attributes, but only some objects > (containers) have items.
The C++ STL has a notion of "concepts" that is interesting, although it is naturally syntax-specific since it applies only to one language. http://www.sgi.com/tech/stl/stl_introduction.html After describing the requirements for the first argument to the standard function "find", it says: "Find isn't the only STL algorithm that has such a set of requirements; the arguments to for_each and count, and other algorithms, must satisfy the same requirements. These requirements are sufficiently important that we give them a name: we call such a set of type requirements a concept, and we call this particular concept Input Iterator. We say that a type conforms to a concept, or that it is a model of a concept, if it satisfies all of those requirements. We say that int* is a model of Input Iterator because int* provides all of the operations that are specified by the Input Iterator requirements." Clearly for a cross-language object model, you would have to be more specific about which operations support which concepts. If you were compiling the class MyArray in language Foo, you would not say (using made-up types and concepts) "MyArray satisfies IndexableList" but rather "(MyArray, __item__) satisfies IndexableList." Then when an instance of MyArray was indexed using [] in Python or Ruby, the call would be linked or dispatched to __item__. If this information can be maintained and used at runtime in a reasonably efficient way, or even used at compile-time to augment a type with standardly-named operations, that would be extremely exciting for me as a language user. However (as a language *user* only, who lurks on this list out of curiosity) I do not like the idea of "objects having items" being promoted to an object-model-level concept. It would be just as much a (confusing) mistake as promoting "objects having creation dates" or "objects having IDs" to the linguistic level merely because you happen to be working in a database-oriented business language where creation dates and IDs are supported by special syntax. Language syntax that maps to operations such as iteration doesn't change the fact that they are *operations* that happen to be standardized within a language, and potentially across languages, for the sake of supporting syntactic sugar, and not fundamentally different (below the syntactic level) from other operations. I don't think you can distinguish a priori, for the purposes of creating an object model, between operations that might need syntactic sugar and operations that will not. If half a dozen popular languages erupt tomorrow with built-in syntax for date operations ("for obj on Saturday mornings do"), does that mean that "date" is now no longer an attribute and must be raised to a different category on the object-model level? Would you say, "Objects have 'attributes', but they also have 'items' and 'dates'"? On Tue, Mar 25, 2008 at 2:26 PM, Charles Oliver Nutter <[EMAIL PROTECTED]> wrote: > I think perhaps we want to do a quick survey of how most of the key > languages represent collections and try to find the commonality. Where > possible, we should always represent collections in a way that all > languages can see them as such and use them as such, but we also need to > define a bit more clearly where the demarcation is between the low-level > "collection" concept and higher-level duck-typed operations, so we don't > pull in too much for too little gain. I think the demarcation is that the collection concept goes beyond duck typing in order to bridge between languages where "looks like a duck" has different meanings. "It may not look like a duck to you, owing to its lack of a quack() method, but I swear that if you call kvack() it will actually quack like a duck." E.g., my IncrediblyVerboseArray class doesn't have an __item__ method, but if you call its GetItemByNonnegativeIntegerIndex method it does the same thing. Ideally this would be implemented in such a way that there is no final list of concepts, so there are no agonizing decisions about whether to support list slicing or other concepts with marginally popular syntax support. It would be better to allow a language to declare its own extension concepts than to declare the end of syntactic history ;-) (On the other hand, better to have it available, working, and usably fast....) - David --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
