Temporal Classes And Identity

CircleAndEllipseProblem describes the difficulty when we get clashes between attributes and behaviour.

There is a similar problem with OO and classes that change over time.

For example, we have a bank account class. It can either be active or it can be inactive. The attributes and behaviour of each are different. However for an object of type bank account, the id remains the same.

The standard way is to represent the id as an attribute, and then create new class instances whenever the type changes.

It would be nicer to keep the identity, and change the type.

The class invariants need to be enforced. Not all transitions are legal.

This then solves the mutability issue with circle/ellipse.

Are there any programming languages that do this?

-- NickLeaton?

Check out CecilLanguage and PredicateClasses. PredicateDispatching also lets you do it, in a more roundabout way, but the biggest subset of predicate dispatching you're going to get is, again, Cecil. -- JonathanTang

Am I the only one that finds predicate classes absurd?

The only elegant solution when you need an object to change its class is to go ahead and make parent classes dynamic. This is the case in SelfLanguage. I guess this means that prototyping is strictly superior to classing, making them NOT equivalent. -- RichardKulisz

Cecil is a PrototypeBasedLanguage, or at least all the papers on PredicateDispatching describe how to do it with a protoype-based object model. Some of the equivalencies between PatternMatching and PredicateDispatching become significantly easier with prototypes.

This is somewhat expected, as the guy who invented PredicateClasses (CraigChambers?) got his PhD on the Self project.

Not really. When you redefine *parent, you keep all the predicates and they just specialize the new parent (assuming dynamic typing semantics; the Cecil papers specify how to do dispatch with both StaticTyping and DynamicTyping, and dynamic inheritance makes no sense with static typing). But PredicateClasses themselves are often a better, more structured way to handle dynamically-changing class membership. Predicate classes still let you reason statically about a program, something that's completely impossible with dynamic inheritance. And most of the uses for dynamic inheritance (eg. CircleAndEllipseProblem) can be solved just as easily with predicates. -- jt

Oh, and prototypes and classes are equivalent iff you have metaclasses. A MetaClass is just an object that functions like a class, though, so you could argue that it's really a prototype anyway. Except that it still follows the "blueprint" instead of the "prototype" model (it describes how to lay out a class, it doesn't provide a model to copy). -- JonathanTang

For languages that do not allow a class to dynamically change its type, the StatePattern offers one possible solution. Perhaps this page could be merged with DualityBetweenStateAndClass.