> The following is lifted from <a > href="http://scala.epfl.ch/intro/caseclasses.html">http://s > cala.epfl.ch/intro/caseclasses.html</a>: > > <blockquote> > Scala supports the notion of case classes. Case classes > are regular classes which export their constructor > parameters and which provide a recursive decomposition > mechanism via pattern matching. > > Here is an example for a class hierarchy which consists of > an abstract super class Term and three concrete case > classes Var, Fun, and App. > > <pre> > abstract class Term; > case class Var(name: String) extends Term; > case class Fun(arg: String, body: Term) extends Term; > case class App(f: Term, v: Term) extends Term; > </pre> > </blockquote> > > Okay, that is fine, but why not have something like the > following : > > <pre> > class Var { ... } > class Fun { ... } > class App { ... } > > casetype Term { > Var; > Fun; > App; > } > </pre> > How are you proposing to handle constructor parameters? The `case' in a case class essentially tells two things to a Scala compiler:
(1) Define a tag method for instances of the class, so that case selection can be done more quickly.
(2) Keep the constructor parameters around, so that they can be recovered by a pattern match.
Aspect (1) is just an optimization; it can probably be handled by other means. But (2) is different, since it changes the interface of a program. For instance, you might not want to publish the way objects of some class are constructed. In Scala, that's no problem; just don't add a `case' modifier to your class.
In summary, I think case classes are the right abstraction if you want to retrieve constructor parameters in a pattern match. If you do not care about that, then a simple typecase would do just as well.
> How are you proposing to handle constructor parameters?
My proposed case type can not be constructed. Just like a pure abstract base class. You use it as a reference to one of the supertypes in its list.
So:
class Fu { public { def _init(int n) { } } }
class Bar { public { def _init(string s) { } } }
casetype FuBar { Fu; Bar; }
FuBar* fb1 = new Fu(42); FuBar* fb2 = new Bar("fourty-two");
> The `case' in a case class essentially tells two things to > a Scala compiler: > > (1) Define a tag method for instances of the class, so > that case selection can be done more quickly. > > (2) Keep the constructor parameters around, so that they > can be recovered by a pattern match. > > Aspect (1) is just an optimization; it can probably be > handled by other means. But (2) is different, since it > changes the interface of a program. For instance, you > might not want to publish the way objects of some class > are constructed. In Scala, that's no problem; just don't > add a `case' modifier to your class.
Yes, I am sorry I wasn't clear about that. The Scala abstraction is actually quite sophisticated. The pattern matching of constructor parameters is very sophisticated.
> In summary, I think case classes are the right > abstraction > if you want to retrieve constructor parameters in a > pattern match. If you do not care about that, then a > simple typecase would do just as well.
Pardon my ignorance but what is a typecase?
On a slightly different topic how do you define a new subtype in Scala without modifying the supertype's declaration?
PS
Martin, I hope you will consider putting up a blog at Artima, I would love to read it, and I know many other people would be interested as well.
Since the "Term" type identifier doesn't have any properties, it's not really subtyping. It's just syntactic sugar over the standard tagged union. The Haskell syntax is something like:
type Var = ... type Fun = ... type App = ...
data Term = VarT Var | FunT Fun | AppT App
The sytactic sugar: the tag names are automatically derived from the type names and the values automatically get tagged when passed as "Term" parameters.
> Pardon my ignorance but what is a typecase? > It's just a switch statement but with types as tags. Something like the following Scala code:
foo match {
case v: Var => ...
case f: Fun => ...
...
}
Here, Var and Fun need not be case classes. An alternative will be taken if foo has the type given in the label. In the literature, one often uses `typecase' instead of `switch' or `match' for this.
> On a slightly different topic how do you define a new > subtype in Scala without modifying the supertype's > declaration? > You mean "define a supertype without modifying the subtype's declaration"? It cannot be done directly, but you can define an implicit conversion:
implicit def a2b(x: a): b = ...
The conversion will be applied in the scope where it is visible whenever you have a value of type `a' but require an value of type `b'.
> PS > > Martin, I hope you will consider putting up a blog at > Artima, I would love to read it, and I know many other > people would be interested as well.
Thanks for the encouragement! I'll consider it; its just a matter of finding the time to do it.
> Here, Var and Fun need not be case classes. An alternative > will be taken if foo has the type given in the label. In > the literature, one often uses `typecase' instead of > `switch' or `match' for this.
Okay, I see like Modula 3.
> > On a slightly different topic how do you define a new > > subtype in Scala without modifying the supertype's > > declaration? > > > You mean "define a supertype without modifying the > subtype's declaration"?
Yes, sorry about that mistake.
> It cannot be done directly, but > you can define an implicit conversion: > >
> implicit def a2b(x: a): b = ...
>
> The conversion will be applied in the scope where it is > visible whenever you have a value of type `a' but require > an value of type `b'.
Implicit conversions aren't quite a mechanism for subtyping though, because you don't get the additional methods do you?
Do any languages you know support the kind of a-posteriori subtyping I am describing? Is it interesting enough to publish about? Are there other names for it? Sorry for the barrage of questions, but thanks for your help.
> Since the "Term" type identifier doesn't have any > properties, it's not really subtyping. It's just > syntactic sugar over the standard tagged union.
But if I allow methods, then it would be subtyping, wouldn't it?
> The > Haskell syntax is something like: > > > type Var = ... > type Fun = ... > type App = ... > > data Term = VarT Var | FunT Fun | AppT App > > > The sytactic sugar: the tag names are automatically > derived from the type names and the values automatically > get tagged when passed as "Term" parameters.
> a.methodBelongingToB(); // compile error. > implicit def a2b(x: a): b = ... > a.methodBelongingToB(); // compile error? > This works in fact. An implicit conversion is also applied when a selector name is not defined in some expression. This can handle your example. On the other hand, we cannot deal with overriding that way; that's where implicit conversions hit a limit.
> Do any languages you know support the kind of a-posteriori > subtyping I am describing? Is it interesting enough to > publish about? Are there other names for it? Sorry for the > barrage of questions, but thanks for your help.
> > One moe thing, would the case (type) syntax be > statically > > bound? > > I don't understand precisely what you mean. If you are > asking as to whether the type relationships are determined > at compile-time the answer is no.
Then, in a way, this kind of acts like a form of double-dispatch.
I like the idea, but I don't care for implicitly casting inside the case blocks. It's unecessary.
Previous Topic
