A paragraph from CraigChambers, "Predicate Classes"
(ECOOP ?93 Conference Proceedings)

''Predicate classes extend the standard object-oriented modelling constructs by reifying transient states or behavior modes of objects. A predicate class has all the properties of a normal class, including a name, a set of superclasses, a set of methods, and a set of instance variables. Additionally, a predicate class has an associated predicate expression. A predicate class represents the subset of the instances of its superclass(es) that also satisfy the predicate. Whenever an object is an instance of the superclasses of the predicate class, and the predicate expression evaluates to true when invoked on the object, the object will automatically be considered to inherit from the predicate class as well. While the object inherits from a predicate class, it inherits all the methods and instance variables of the predicate class. If the object?s state later changes and the predicate expression no longer evaluates to true, the inheritance of the object will be revised to exclude the predicate class. Predicate classes thus support a form of automatic, dynamic classification of objects, based on their run-time value, state, or other user-defined properties. To the extent that these transient states are important in the application domain, predicate classes can help in modelling and implementing them.''

----
If I understand this, it's kind of like this ...

 Predicate''''''Class>>someMethod
   self predicate ifFalse: [^super someMethod].
   "continue with method for Predicate''''''Class ..."

''In a warped and twisted way, yes.''
----
In effect, yes; it's a way of replacing "if" statements with dynamic method dispatch.

For example, if your base class is a ring-buffer, you can represent the states buffer-full, buffer-empty, buffer-not-full, buffer-not-empty and buffer-partially-full as predicate subclasses (with the obvious inheritance relations). Then you can add code to these subclasses in the usual way. The base class declares a routine that fetches an item from the buffer, which you can override differently in buffer-empty and buffer-not-empty subclasses.

The Smalltalk snippet is a bit misleading because #ifFalse: can only make binary choices. With dynamic method dispatch you can make multi-way choices, one for each subclass. It is also misleading in what it says about the way code is organized. With dynamic method dispatch you keep all the related code together in its class, and separate from unrelated code. These advantages carry over to predicate classes quite naturally. -- DaveHarris

''Anyone care to explain this further and maybe give some javaish examples?''
 
No. The explanation so far is more than clear. What isn't clear is:

* what the hell predicate classes are good for?
* why it is that this esoteric fairy feature is worth the COST of learning to use it? Anyone remember ClassTalk? No? Oh, yeah, that's because nobody uses it!
* why they exist given that their inventor got his PhD working in SelfLanguage where such things would be useless?
* why language designers persist in creating nifty but useless features instead of consolidating the 30 years of research they're behind on?

''Who is the aggressor on this page? Same as on LearningFromPrototypes? Does anyone actually consider this material's content to outweigh its presentation, or may I just delete it?'' --AdamBerger

I wrote it. And the aggression is pretty restrained.

Do you even know what a predicate class is? It's a giant honking case statement in a method that says:
* IF <this situation> THEN delegate <there>
* IF <that situation> THEN delegate <over there>
* ...

That's all it is. Syntactic sugar for a common case of delegation. With the marked disadvantage that it ''forces'' you to clearly and consistently express all of the conditions necessary to get into the different states.

With delegation, you can just put a predicate check like "self full ifTrue: [parent* become: Full''''''Buffer]." wherever you want. When your predicates are unclear, complex and inconsistent, delegation is the only way to express them in a simple manner. And when your predicates ''are'' clear, simple and consistent, then it's equally simple to put in "self checkPredicates.", or just "checkPredicates." in SelfLanguage, at the beginning of your methods.

''If you do this: [parent* become: F''''''ullBuffer] then you are mutating state. Predicate classes can work with immutable objects. Also it is possible for an object to be a member of multiple predicate classes simultaneously, which is not possible with a mutable parent. For example, the number 2 is a member of Integer, E''''''venNumber, P''''''owerOfTwo and P''''''rimeNumber. -- JamesMcCartney''

''An object can be a member of multiple mutable parent classes at once too.  Just have one be a subclass of the others.  If they don't form a strait membership relationship, you'll need multiple inheritance.  In your example, you'd have the class hierarchy Integer -> P''''''owerOfTwo -> E''''''venNumber and P''''''rimeNumber, with 2 having both hierarchies as parents.  -- JonathanTang''

''You mean: P''''''owerOfTwo -> E''''''venNumber -> Integer''

''The problem is in a language with mutable state, if an object changes state such that it goes from being a member of one class to several classes, you then have to add parent slots in a prototype model. And when it changes state to become a member of fewer predicate classes, you would have to remove parent slots in a prototype model. This management of parents is a huge burden which is not necessary with predicate classes. Parents that represent predicate classes are redundant state and have all the disadvantages of managing redundant state, i.e. if you ever miss a place where that state needs to be synced, then the object has corrupt type. This kind of programming error is not possible with predicate classes. -- JamesMcCartney''

And the advantage of doing it this way is that there's '''no new syntax'''!

The problem with predicate classes is that they're smack in the middle of an abstraction stack where:
* SingleDispatch, is a specialization of
* MultipleDispatch, which is a specialization of
* PatternMatching, which is a specialization of 
* PredicateDispatching, which is a specialization of
* Explicit test and delegation (the big IF/CASE statement).

''I'm sure TableOrientedProgramming fits in there somewhere... I'd say between multiple and predicate dispatch, except that TOP doesn't seem to handle types at all. Whenever the matter is mentioned, topmind just replies that ThereAreNoTypes.''

* No. I didn't even create that topic. See the note near the top. -t

As an abstraction, their usefulness is squeezed between multiple dispatch at the low end and delegation at the high end. Multiple dispatch being less, and delegation far more, general than predicate dispatch.

So just how useful are predicate classes? Nobody knows because predicate classes have ''never been implemented''. And before implementing them, before making the VM send checkPredicates on every message send, before we make checkPredicates an implicit message send at the beginning of every method, why don't we first find out if anyone ''uses'' the damn things explicitly?

Until we do, it's best to think of predicate classes as FUD. Especially since their inventor was fully aware of delegation, having worked in Self for years. Especially since there are so many ways to completely fuck up predicate classes in a language that doesn't have delegation. What comes immediately to mind is some idiot inventing special syntax for predicate classes and not reifying predicate classes as real classes. And ''that'' justifies the aggression. -- RK

I thought someone had responded to RK already, but I guess not.  The syntactic sugar is ''everything''.  I find that I often write code that needs to check whether an object has been initialized, whether it's waiting on more data, whether it's written out data, whether it's in a consistent state, etc.  Checking these conditions means a large number of guard clauses at the beginning of each method.  In well-factored code I've seen, error and sanity checks account for well over 50% of the code.  A typical 12-line method might have 8 lines of error checking, and then a 4-line loop that does the actual work.

PredicateClasses let you group all these conditions together in one logical place.  If these conditions hold, then that's what the type of the object is.  I'd much rather specify a few conditions than try to remember to insert become: calls every time an object's state changes.  OnceAndOnlyOnce.

There's an interesting analogy with stack & function call management.  There the "abstraction stack" is:
* LIFO calls only, no nested functions (K & R CeeLanguage, I think).
* LIFO calls, no nested functions, early non-local exits (C with setjmp/longjmp, early Java, C++)
* Nested functions with 2nd-class LexicalClosure''''''s (Algol, Pascal, Java)
* FirstClassFunction''''''s (Perl)
* FirstClassFunction''''''s + limited coroutine/generator support (Icon, Ruby, Python)
* FirstClassContinuation''''''s (Scheme)
* Dynamic inspection of stack contents (SmallTalk, CommonLisp [sorta], TCL)
* Explicit stack manipulation and GoTo (AssemblyLanguage)

Here, by far the most expressive is an explicit stack and jump.  You're not constrained to LIFO function order.  You can save whatever contents you need.  You can make efficiency tradeoffs based on anticipated usage.

I also don't know many programmers who enjoy programming in assembly and managing their own stacks.

Indeed, the most commonly used languages all fall into the first half of the "abstraction stack" (I put that in quotes because it really measures expressiveness, not abstraction).  That's because of the well-known dictum of OptimizeForTheCommonCase.  Most programs really don't need the extra power; they do just fine with what they've got.  And in the cases where you do (continuations or explicit inspection of the stack), they don't want to go back to handling all the common cases explicitly.

Dispatch is the same way.  If people really want to do explicit delegation through if/case statements, they certainly can.  But predicate classes cover a "common case" that in my experience has been the source of many bugs.  -- JonathanTang

----
As an aside, it is false to say they have never been implemented: They are quite functional in the little-known system agent simulation system Easel.

See 
*** http://www.sei.cmu.edu/community/easel/ ( BrokenLink ) 
----

There is also Cecil which implements PredicateTypes -- StefanPlantikow

----

Of course, if we replaced all of the other forms of dynamic dispatch with delegation--we'd be back to procedural programming. And I don't think anybody considers that a step forward. The advantage(s) of the various forms of ObjectOriented dynamic dispatch - prototype-based or class-based - are as follows:

* Least importantly, performance. In some cases (if you have lots of cases, especially), this can be significant. SingleDispatch can always be made O(1) with a VeeTable or a prototype-and-slot implementation, there are lots of fast ways of doing multiple dispatch as well. Explicit delegation is O(''n'') in general, where ''n'' is the number of cases to consider. (In some instances it can be made faster). I have doubts whether or not general-purpose predicate classes can be made faster than O(''n''). In addition, predicates generally impose an ordering, as detecting overlap of arbitrary predicates at compile-time is undecidable. (Doing it at runtime is possible, but a gross waste of CPU resources...)

* In some cases, it's a better way of communicating to the programmer what the heck is going on.

* The different cases can be specified at different points in the code. If I override a method in a derived class, or change a slot in some object, I don't have to go mess with the base class or the prototype. With explicit dispatch, I do. PredicateClasses seem to be an attempt to get the expressiveness of explicit delegation, but allowing the various cases to be decoupled from each other. Like you, I have doubts about the usefulness of this--the example often cited in the literature (specializing queue methods based on whether or not the queue is empty or full) can be handled adequately with PatternMatching; and I think PatternMatching implementations are clearer. Sometimes it's better to structure by noun, sometimes by verb.

----

1. A sometimes overlooked feature of predicative classes is their usefulness for contract-based programming, especially due to the fact that they are semantically stricter than simple interfaces.

2. As has already been said here, another important aspect of predicate classes is that they allow a certain way of cross-cutting the type system (AspectOrientedProgramming) by providing means for dynamically run-time grouping of otherwise unrelated types together (like interfaces do statically). In a statically [typed?] language, this leads to the doubtful possibility of "type-loss".

A very simple approach to this would be to limit state change and aliasing storage of predicatively typed objects, thus allowing the use of dynamic, predicative typing only in a dynamic context. A "javaish example" that just came to my mind:

 class SomethingThatNeedsAQueue
 {
    Queue q1;
    Queue being Empty q2;   // Compiler Error, would allow predicative aliasing

    void foo(Queue staying Empty q) {
           // Implied thread lock around q

            Queue being Empty q3;

            q1 = q;  // ok
            q3 = q;  // ok
       
            q.size;   // ok
            q.enqueue(foo)  // RuntimeException if Empty predicate not true after call
   }

   void bar(Queue being Empy becoming Full q) {
           // Implied thread lock around q

           q.enqueue(foo);  // ok
   }
 }

-- StefanPlantikow


------

Why is it even called a "class"? Somebody pointed out in another topic that I can't find again (perhaps related to AttributesInNameSmell or SetsAndPolymorphism) that a truly predicate-based call would look something like:

  do(verb="xxx", noun="xxx", adjective="xx", foo="xx", bar="etc...");

Such is almost ProLog-like. In practice is often difficult to get one's head around such. With a method call or a function call, you know that you are calling either one noun or one verb. The above may result in zero or many segments/snippets/actions being triggered. The MentalIndexability uncertainty is too high for most people unless a new way to teach a change in thinking is found. --top

----

See also PredicateTypes