This page is no longer maintained — Please continue to the home page at www.scala-lang.org

usecase for sealed / match (improvement for OO programming)

2 replies
Stefan Wachter
Joined: 2009-09-18,
User offline. Last seen 42 years 45 weeks ago.

Hi all,

I try to implement the XML data model in Scala. The XML data model is
very rich in that it incorporates the XML schema data model and the
XPath 2.0 data model. Therefore I would really like to define the so
called "items" (elements, attributes, atomic values, ...) using
interfaces (i.e. traits without implementations).

When processing these items the match expression comes in handy.
Depending on the situation sometimes nodes have to processed or atomic
values or processing instructions, or ... The match should be based on
the item interfaces and coverage should be checked by the compiler. Yet,
it should be possible to add additional implementations of items.

I try to illustrate what I mean with an example: The interface hierarchy
is defined in a single file using the "sealed" keyword to indicate that
a coverage check should be performed by the compiler:

Interface-File
===========

sealed trait IItem

sealed trait ISimpleValue

trait INode extends IItem

trait IElement extends INode

trait IText extends INode

trait IAttribute extends INode

trait IListValue extends ISimpleValue

trait IAtomicValue[O] extends IItem with ISimpleValue

trait IBooleanValue extends IAtomicValue[Boolean]

trait IUntypedAtomicValue extends IAtomicValue[String]

trait IDecimalValue extends IAtomicValue[BigDecimal]

trait IIntegerValue extends IAtomicValue[BigInteger]

trait ILongValue extends IAtomicValue[Long]

trait IIntValue extends IAtomicValue[Int]

With these definitions in place the compiler should be able to check the
coverage of the following match expressions:

------------
val v: IItem
v match {
case IElement => ...
case IAttribute => ...
case IText => ...
case IAtomicValue => ...
}
------------
val v: ISimpleValue
v match {
case IListValue => ...
case IAtomicValue => ...
}
------------
val v: ISimpleValue
v match {
case IListValue => ...
case IBooleanValue => ...
case IDecimalValue => ...
....
}
-------

At the moment this does not work. The "sealedness" is not transitive,
i.e. the compiler finds unsealed subtypes and therefore does no coverage
check. In addition, it is not allowed to extends sealed types which
prevents an implementation from extending the IItem trait.

If the meaning of the "sealed" keyword would be changed then the
presented usecase could be handled. The new meaning would be:

1. "sealed" is transitive for the types defined in the same file. (This
is only a cosmetic change)
2. Sealed types can be extended by types that reside in different files.
Yet, these "extension" types are not considered in the coverage check of
the compiler.

This new "sealedness" concept improves the situation if an
implementation hierarchy gets large but the match should not be
interested in the specific implementations but on more general
classifications. One could say that the new concept would improve the OO
aspect of Scala with regard to the match expressions.

Thanks you for your attention. I am curious about your opinions!

--Stefan

Stefan Wachter
Joined: 2009-09-18,
User offline. Last seen 42 years 45 weeks ago.
Re: usecase for sealed / match (improvement for OO programming)

Are there no opinions on this topic? That's a pitty!

--Stefan

Am 12.02.2010 23:48, schrieb Stefan Wachter:
> Hi all,
>
> I try to implement the XML data model in Scala. The XML data model is
> very rich in that it incorporates the XML schema data model and the
> XPath 2.0 data model. Therefore I would really like to define the so
> called "items" (elements, attributes, atomic values, ...) using
> interfaces (i.e. traits without implementations).
>
> When processing these items the match expression comes in handy.
> Depending on the situation sometimes nodes have to processed or atomic
> values or processing instructions, or ... The match should be based on
> the item interfaces and coverage should be checked by the compiler. Yet,
> it should be possible to add additional implementations of items.
>
> I try to illustrate what I mean with an example: The interface hierarchy
> is defined in a single file using the "sealed" keyword to indicate that
> a coverage check should be performed by the compiler:
>
> Interface-File
> ===========
>
> sealed trait IItem
>
> sealed trait ISimpleValue
>
> trait INode extends IItem
>
> trait IElement extends INode
>
> trait IText extends INode
>
> trait IAttribute extends INode
>
> trait IListValue extends ISimpleValue
>
> trait IAtomicValue[O] extends IItem with ISimpleValue
>
> trait IBooleanValue extends IAtomicValue[Boolean]
>
> trait IUntypedAtomicValue extends IAtomicValue[String]
>
> trait IDecimalValue extends IAtomicValue[BigDecimal]
>
> trait IIntegerValue extends IAtomicValue[BigInteger]
>
> trait ILongValue extends IAtomicValue[Long]
>
> trait IIntValue extends IAtomicValue[Int]
>
>
> With these definitions in place the compiler should be able to check the
> coverage of the following match expressions:
>
> ------------
> val v: IItem
> v match {
> case IElement => ...
> case IAttribute => ...
> case IText => ...
> case IAtomicValue => ...
> }
> ------------
> val v: ISimpleValue
> v match {
> case IListValue => ...
> case IAtomicValue => ...
> }
> ------------
> val v: ISimpleValue
> v match {
> case IListValue => ...
> case IBooleanValue => ...
> case IDecimalValue => ...
> ....
> }
> -------
>
>
> At the moment this does not work. The "sealedness" is not transitive,
> i.e. the compiler finds unsealed subtypes and therefore does no coverage
> check. In addition, it is not allowed to extends sealed types which
> prevents an implementation from extending the IItem trait.
>
> If the meaning of the "sealed" keyword would be changed then the
> presented usecase could be handled. The new meaning would be:
>
> 1. "sealed" is transitive for the types defined in the same file. (This
> is only a cosmetic change)
> 2. Sealed types can be extended by types that reside in different files.
> Yet, these "extension" types are not considered in the coverage check of
> the compiler.
>
> This new "sealedness" concept improves the situation if an
> implementation hierarchy gets large but the match should not be
> interested in the specific implementations but on more general
> classifications. One could say that the new concept would improve the OO
> aspect of Scala with regard to the match expressions.
>
> Thanks you for your attention. I am curious about your opinions!
>
> --Stefan
>
>

nilskp
Joined: 2009-01-30,
User offline. Last seen 1 year 27 weeks ago.
Re: usecase for sealed / match (improvement for OO programming
On Mon, Feb 22, 2010 at 5:00 AM, Stefan Wachter <Stefan [dot] Wachter [at] gmx [dot] de> wrote:
Are there no opinions on this topic? That's a pitty!

It may be because you prefix your traits with I.

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland