>> Why? That is, why can't you imagine making a claim that type >> X meets interface Y, even though the author of neither X nor Y >> made that claim? Oren> It's not a failure of imagination, it's a failure of Oren> terminology. In contexts where the term 'interface' is used Oren> (Java, COM, etc) it usually means something you explicitly Oren> expose from your objects. I find that the term 'category' Oren> implies something you observe after the fact without modifying Oren> the object - "these objects both have property so-and-so, let's Oren> group them together and call it a category". But what if it is possible to express property so-and-so as an interface? It's like observing that a particular set, that someone else defined, is a group, so now all the group theorems apply to it. Similarly, if someone has defined a class, and I happen to notice that that class is really a reversible iterator, I would like a way saying so that will let anyone who wants to use that class in a context that requires a reversible iterator to do so. >> However, now that you bring it up... One difference I see between >> interfaces and categories is that I can imagine categories carrying >> semantic information to the human reader of the code that is not >> actually expressed in the category itself. As a simple example, >> I can imagine a PartialOrdering category that I might like as part >> of the specification for an argument to a sort function. Oren> You can define any category you like and attach a semantic Oren> meaning to it as long as you can write a membership predicate Oren> for the category. It may be based on a marker that the type must Oren> have or, in case you can't change the type (e.g. a builtin type) Oren> you can write a membership predicate that also tests for some Oren> set of specific types. Or perhaps a membership predicate that tests whether a type satisfies a particular interface. Oren> A category is defined mathematically by a membership Oren> predicate. So what we need for type categories is a system for Oren> writing predicates about types. And, perhaps, a way for defining predicates that determine whether types meet interfaces. >> Indeed, that's what I was thinking about initially. Guido pointed >> out that the notion could be expanded to making concrete assertions >> about the interface to a class. I had originally considered that >> those assertions could be just that--assertions, but then when >> Guido started talking about interfaces, I realized that my original >> thought of expressing satisfaction of a predicate by inheriting it >> could be extended by simply adding methods to those predicates. Of >> course, this technique has the disadvantage that it's not easy to >> add base classes to a class after it has been defined. Oren> That's why the intelligence should be in the membership Oren> predicate, not in the classes it selects. Nothing needs to be Oren> changed about types. Conceptually, categories apply to Oren> *references*, not to *objects*. I don't see why categories should not also apply to class objects. Oren> They help you ensure that during execution certain references Oren> may only point to objects from a limited category of types so Oren> that the operations you perform on them are meaningful (though Oren> not necessarily correct). A situation that may lead to a Oren> reference pointing to an object outside the valid category Oren> should be detected as early as possible. Detecting this during Oren> compilation is great. On module import is good. At runtime it's Oren> ok. Agreed. Oren> Can you can think of a better name than 'categories' to describe Oren> a set of types selected by a membership predicate? Not offhand. -- Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4