|
Collections in 2.8: Why extends the collection traits their implementation traits (and not the other way round)?
Hi all,
I took a closer look on the collections in 2.8 and read the SID for
collections ( http://www.scala-lang.org/sids).
Having my (basic) OO knowledge in mind I expected to find pure abstract
traits (i.e. interfaces) that describe the basic kinds of collections.
Then these interfaces would be implemented somehow.
Yet, what I found were traits that stand for certain collection concepts
(like Traversable or Iterable) that inherit lots of implementation code
from so called template traits (named TraversableLike or IterableLike,
respectively) and do not add any further aspects.
I think that this design can make custom implementations of collections
more difficult.
For example if I want to develop a trait that allows to view single
instances as traversables with a single member then I must look really
carefully at the TraversableLike trait and watch out for all methods
that should be handled differently. For example TraversableLike
implements the isEmpty method by:
def isEmpty: Boolean = {
var result = true
breakable {
for (x <- this) {
result = false
break
}
}
result
}
Clearly, a "SingleTraversable" can do better:
override def isEmpty: Boolean = false
If the TraversableLike trait changes in future I might miss some of the
methods that should be overriden and fallback on inefficient
implementations.
Therefore I think that it would be better to have pure abstract
collection traits that have to be implemented.
Cheers,
--Stefan
PS: Is there more material available for the new 2.8 collections?
|
|
Re: Collections in 2.8: Why extends the collection traits their implementation traits (and not the other way round)?
Your best bet if you want a "SingleTraversable" is to use Option, it
has the full compliment of map/flatmap/foreach methods that you'll be
needing
On Thu, Oct 22, 2009 at 9:32 AM, Stefan Wachter < Stefan.Wachter@...> wrote:
> Hi all,
>
> I took a closer look on the collections in 2.8 and read the SID for
> collections ( http://www.scala-lang.org/sids).
>
> Having my (basic) OO knowledge in mind I expected to find pure abstract
> traits (i.e. interfaces) that describe the basic kinds of collections. Then
> these interfaces would be implemented somehow.
>
> Yet, what I found were traits that stand for certain collection concepts
> (like Traversable or Iterable) that inherit lots of implementation code from
> so called template traits (named TraversableLike or IterableLike,
> respectively) and do not add any further aspects.
>
> I think that this design can make custom implementations of collections more
> difficult.
>
> For example if I want to develop a trait that allows to view single
> instances as traversables with a single member then I must look really
> carefully at the TraversableLike trait and watch out for all methods that
> should be handled differently. For example TraversableLike implements the
> isEmpty method by:
>
> def isEmpty: Boolean = {
> var result = true
> breakable {
> for (x <- this) {
> result = false
> break
> }
> }
> result
> }
>
> Clearly, a "SingleTraversable" can do better:
>
> override def isEmpty: Boolean = false
>
> If the TraversableLike trait changes in future I might miss some of the
> methods that should be overriden and fallback on inefficient
> implementations.
>
> Therefore I think that it would be better to have pure abstract collection
> traits that have to be implemented.
>
> Cheers,
>
> --Stefan
>
> PS: Is there more material available for the new 2.8 collections?
>
>
|
|
 Re: Collections in 2.8: Why extends the collection traits their implementation traits (and not the other way round)?
Hard to comment without knowing your exact use-case
but... you can happily use for-comprehensions on Option, which might
take away some of your pain.
On Thu, Oct 22, 2009 at 10:33 AM, Stefan Wachter < Stefan.Wachter@...> wrote:
> Hi Kevin,
>
> thanks for the suggestion.
>
> In fact Option implements many of the methods that you find at Traversable,
> but unfortunately it is not derived from Traversable. If you want to use an
> Option as a Traversable in a method call then (afaik) it would be possible
> only by a structural type with its negative performance impact.
>
> I think it would be nice to have Option mixing in Traversable. But it seems
> to make not much sense that Options inherits the implementation from
> TraversableLike. This illustrates the point I tried to make with my original
> post.
>
> Cheers,
> --Stefan
>
>
>
> Kevin Wright wrote:
>
> Your best bet if you want a "SingleTraversable" is to use Option, it
> has the full compliment of map/flatmap/foreach methods that you'll be
> needing
>
> On Thu, Oct 22, 2009 at 9:32 AM, Stefan Wachter < Stefan.Wachter@...>
> wrote:
>
>
> Hi all,
>
> I took a closer look on the collections in 2.8 and read the SID for
> collections ( http://www.scala-lang.org/sids).
>
> Having my (basic) OO knowledge in mind I expected to find pure abstract
> traits (i.e. interfaces) that describe the basic kinds of collections. Then
> these interfaces would be implemented somehow.
>
> Yet, what I found were traits that stand for certain collection concepts
> (like Traversable or Iterable) that inherit lots of implementation code from
> so called template traits (named TraversableLike or IterableLike,
> respectively) and do not add any further aspects.
>
> I think that this design can make custom implementations of collections more
> difficult.
>
> For example if I want to develop a trait that allows to view single
> instances as traversables with a single member then I must look really
> carefully at the TraversableLike trait and watch out for all methods that
> should be handled differently. For example TraversableLike implements the
> isEmpty method by:
>
> def isEmpty: Boolean = {
> var result = true
> breakable {
> for (x <- this) {
> result = false
> break
> }
> }
> result
> }
>
> Clearly, a "SingleTraversable" can do better:
>
> override def isEmpty: Boolean = false
>
> If the TraversableLike trait changes in future I might miss some of the
> methods that should be overriden and fallback on inefficient
> implementations.
>
> Therefore I think that it would be better to have pure abstract collection
> traits that have to be implemented.
>
> Cheers,
>
> --Stefan
>
> PS: Is there more material available for the new 2.8 collections?
>
>
>
>
>
>
|
|
Re: Collections in 2.8: Why extends the collection traits their implementation traits (and not the other way round)?
Adriaan thinks it would be nice to have an "extendsInterface"-like keyword, where you get the interface of a type, but not its implementation. Then you could say that you implement the implicit interface of these traits that contain code, and you would not get any default implementations.
Donna On Thu, Oct 22, 2009 at 11:48 AM, Kevin Wright <kev.lee.wright@...> wrote:
Hard to comment without knowing your exact use-case
but... you can happily use for-comprehensions on Option, which might
take away some of your pain.
On Thu, Oct 22, 2009 at 10:33 AM, Stefan Wachter <Stefan.Wachter@...> wrote:
> Hi Kevin,
>
> thanks for the suggestion.
>
> In fact Option implements many of the methods that you find at Traversable,
> but unfortunately it is not derived from Traversable. If you want to use an
> Option as a Traversable in a method call then (afaik) it would be possible
> only by a structural type with its negative performance impact.
>
> I think it would be nice to have Option mixing in Traversable. But it seems
> to make not much sense that Options inherits the implementation from
> TraversableLike. This illustrates the point I tried to make with my original
> post.
>
> Cheers,
> --Stefan
>
>
>
> Kevin Wright wrote:
>
> Your best bet if you want a "SingleTraversable" is to use Option, it
> has the full compliment of map/flatmap/foreach methods that you'll be
> needing
>
> On Thu, Oct 22, 2009 at 9:32 AM, Stefan Wachter < Stefan.Wachter@...>
> wrote:
>
>
> Hi all,
>
> I took a closer look on the collections in 2.8 and read the SID for
> collections ( http://www.scala-lang.org/sids).
>
> Having my (basic) OO knowledge in mind I expected to find pure abstract
> traits (i.e. interfaces) that describe the basic kinds of collections. Then
> these interfaces would be implemented somehow.
>
> Yet, what I found were traits that stand for certain collection concepts
> (like Traversable or Iterable) that inherit lots of implementation code from
> so called template traits (named TraversableLike or IterableLike,
> respectively) and do not add any further aspects.
>
> I think that this design can make custom implementations of collections more
> difficult.
>
> For example if I want to develop a trait that allows to view single
> instances as traversables with a single member then I must look really
> carefully at the TraversableLike trait and watch out for all methods that
> should be handled differently. For example TraversableLike implements the
> isEmpty method by:
>
> def isEmpty: Boolean = {
> var result = true
> breakable {
> for (x <- this) {
> result = false
> break
> }
> }
> result
> }
>
> Clearly, a "SingleTraversable" can do better:
>
> override def isEmpty: Boolean = false
>
> If the TraversableLike trait changes in future I might miss some of the
> methods that should be overriden and fallback on inefficient
> implementations.
>
> Therefore I think that it would be better to have pure abstract collection
> traits that have to be implemented.
>
> Cheers,
>
> --Stefan
>
> PS: Is there more material available for the new 2.8 collections?
>
>
>
>
>
>
|
|
RE: Collections in 2.8: Why extends the collection traits their implementation traits (and not the other way round)?
Isn't the basic idea
that you can simply implement foreach() in your custom collection, and
implementing other methods is just for optimisation? If so, I think that is
pretty good as far as a collection library goes. :-)
Kieron
Hi all, I took a closer look on the collections in 2.8 and read the
SID for collections ( http://www.scala-lang.org/sids).
Having my (basic) OO knowledge in mind I expected to find pure abstract
traits (i.e. interfaces) that describe the basic kinds of collections.
Then these interfaces would be implemented somehow. Yet, what I
found were traits that stand for certain collection concepts (like
Traversable or Iterable) that inherit lots of implementation code from so
called template traits (named TraversableLike or IterableLike, respectively)
and do not add any further aspects. I think that this design can make
custom implementations of collections more difficult. For example if
I want to develop a trait that allows to view single instances as
traversables with a single member then I must look really carefully at the
TraversableLike trait and watch out for all methods that should be handled
differently. For example TraversableLike implements the isEmpty method by:
def isEmpty: Boolean = { var result = true breakable { for
(x < - this) { result = false break } } result }
Clearly, a "SingleTraversable" can do better: override def
isEmpty: Boolean = false If the TraversableLike trait changes in future
I might miss some of the methods that should be overriden and fallback on
inefficient implementations. Therefore I think that it would be
better to have pure abstract collection traits that have to be implemented.
Cheers, --Stefan PS: Is there more material available
for the new 2.8 collections?
Information
Classification: Public
This message may contain confidential and privileged information and is intended solely for the use of the named addressee. Access, copying or re-use of the e-mail or any information contained therein by any other person is not authorised. If you are not the intended recipient please notify us immediately by returning the e-mail to the originator and then immediately delete this message. Although we attempt to sweep e-mail and attachments for viruses, we do not guarantee that either are virus-free and accept no liability for any damage sustained as a result of viruses.
Please refer to http://www.bnymellon.com/disclaimer/piml.html for certain disclosures.
|
|
Re: Collections in 2.8: Why extends the collection traits their implementation traits (and not the other way round)?
not quite...
foreach is used when all the behaviour of your traversal will be via
side-effects
(println is a good example of this, a call to println doesn't return anything)
map is used when you want to convert each element to something else
and store it in a new container
so an expression like
for(x <- myCollection) yield x.someProperty
will be compiled as
myCollection.map(x -> x.someProperty)
but if you leave out the yield and rely on side effects:
for(x <- myCollection) println(x.someProperty)
then it becomes
myCollection.foreach(x -> println(x.someProperty))
flatMap gets used with more complex for-comprehensions
So...
If you're only using the yield form, you need to implement map and flatMap
If you're never using the yield form, then you only need foreach
Generally it's good practice to implement all three methods.
On Thu, Oct 22, 2009 at 11:06 AM, < Kieron.Wilkinson@...> wrote:
> Isn't the basic idea that you can simply implement foreach() in your custom
> collection, and implementing other methods is just for optimisation? If so,
> I think that is pretty good as far as a collection library goes. :-)
>
> Kieron
>
> ________________________________
> From: Stefan Wachter < Stefan.Wachter@...> [mailto:Stefan Wachter
> < Stefan.Wachter@...>]
> Sent: 22 October 2009 09:32
> To: scala-debate@...
> Subject: [scala-debate] Collections in 2.8: Why extends the collection
> traits their implementation traits (and not the other way round)?
>
> Hi all,
>
> I took a closer look on the collections in 2.8 and read the SID for
> collections ( http://www.scala-lang.org/sids).
>
> Having my (basic) OO knowledge in mind I expected to find pure abstract
> traits (i.e. interfaces) that describe the basic kinds of collections.
> Then these interfaces would be implemented somehow.
>
> Yet, what I found were traits that stand for certain collection concepts
> (like Traversable or Iterable) that inherit lots of implementation code
> from so called template traits (named TraversableLike or IterableLike,
> respectively) and do not add any further aspects.
>
> I think that this design can make custom implementations of collections
> more difficult.
>
> For example if I want to develop a trait that allows to view single
> instances as traversables with a single member then I must look really
> carefully at the TraversableLike trait and watch out for all methods
> that should be handled differently. For example TraversableLike
> implements the isEmpty method by:
>
> def isEmpty: Boolean = {
> var result = true
> breakable {
> for (x < - this) {
> result = false
> break
> }
> }
> result
> }
>
> Clearly, a "SingleTraversable" can do better:
>
> override def isEmpty: Boolean = false
>
> If the TraversableLike trait changes in future I might miss some of the
> methods that should be overriden and fallback on inefficient
> implementations.
>
> Therefore I think that it would be better to have pure abstract
> collection traits that have to be implemented.
>
> Cheers,
>
> --Stefan
>
> PS: Is there more material available for the new 2.8 collections?
>
>
>
> Information Classification: Public
>
> This message may contain confidential and privileged information and is
> intended solely for the use of the named addressee. Access, copying or
> re-use of the e-mail or any information contained therein by any other
> person is not authorised. If you are not the intended recipient please
> notify us immediately by returning the e-mail to the originator and then
> immediately delete this message. Although we attempt to sweep e-mail and
> attachments for viruses, we do not guarantee that either are virus-free and
> accept no liability for any damage sustained as a result of viruses.
>
> Please refer to http://www.bnymellon.com/disclaimer/piml.html for certain
> disclosures.
>
|
|
Re: Collections in 2.8: Why extends the collection traits their implementation traits (and not the other way round)?
Hi Kevin,
Kevin Wright <kev.lee.wright <at> googlemail.com> writes:
> not quite...
> foreach is used when all the behaviour of your traversal will be via
> side-effects
I think you misunderstood what Kieron was saying. Here's part of the javadoc for
Traversable:
* <p>
* Collection classes mixing in this trait provide a method
* <code>foreach</code> which traverses all the
* elements contained in the collection, applying a given procedure to each.
* They also provide a method <code>newBuilder</code>
* which creates a builder for collections of the same kind.
* </p>
That is what he meant by implement foreach and get the rest for free, I believe.
Best,
Ismael
|
|
Re: Collections in 2.8: Why extends the collection traits their implementation traits (and not the other way round)?
Hi Donna & Kevin,
I think "extendsInterface" would do the job. Yet, I think the better
solution would be to have pure abstract traits (i.e. interfaces) at the
top of the collection hierarchy.
If I have a concrete implementation of a Traversable then I could
either choose to extend TraversableLike (and inherit all its
implementation) or I could choose to extends Traversable (which would
not extend TraversableLike) and implement everything myself.
Maybe it would be possible to make TraversableLike more granular, i.e.
split it into serveral implementation traits. One trait could be
responsible for map, flatMap, and filter. Then a concrete traversable
could decide which parts of the implementation it wants to reuse.
I must admit that my understanding of the collection library is not
very deep. But I have the feeling, that the design of the collection
library is strongly driven by "implementation inheritance". I do not
understand why this way was choosen because traits would allow to mixin
implementations flexibly into the concrete classes.
Cheers,
--Stefan
Donna Malayeri wrote:
Adriaan thinks it would be nice to have an
"extendsInterface"-like keyword, where you get the interface of a type,
but not its implementation. Then you could say that you implement the
implicit interface of these traits that contain code, and you would not
get any default implementations.
Donna
On Thu, Oct 22, 2009 at 11:48 AM, Kevin
Wright <kev.lee.wright@...>
wrote:
Hard
to comment without knowing your exact use-case
but... you can happily use for-comprehensions on Option, which might
take away some of your pain.
On Thu, Oct 22, 2009 at 10:33 AM, Stefan Wachter <Stefan.Wachter@...>
wrote:
> Hi Kevin,
>
> thanks for the suggestion.
>
> In fact Option implements many of the methods that you find at
Traversable,
> but unfortunately it is not derived from Traversable. If you want
to use an
> Option as a Traversable in a method call then (afaik) it would be
possible
> only by a structural type with its negative performance impact.
>
> I think it would be nice to have Option mixing in Traversable. But
it seems
> to make not much sense that Options inherits the implementation
from
> TraversableLike. This illustrates the point I tried to make with
my original
> post.
>
> Cheers,
> --Stefan
>
>
>
> Kevin Wright wrote:
>
> Your best bet if you want a "SingleTraversable" is to use Option,
it
> has the full compliment of map/flatmap/foreach methods that you'll
be
> needing
>
> On Thu, Oct 22, 2009 at 9:32 AM, Stefan Wachter < Stefan.Wachter@...>
> wrote:
>
>
> Hi all,
>
> I took a closer look on the collections in 2.8 and read the SID for
> collections ( http://www.scala-lang.org/sids).
>
> Having my (basic) OO knowledge in mind I expected to find pure
abstract
> traits (i.e. interfaces) that describe the basic kinds of
collections. Then
> these interfaces would be implemented somehow.
>
> Yet, what I found were traits that stand for certain collection
concepts
> (like Traversable or Iterable) that inherit lots of implementation
code from
> so called template traits (named TraversableLike or IterableLike,
> respectively) and do not add any further aspects.
>
> I think that this design can make custom implementations of
collections more
> difficult.
>
> For example if I want to develop a trait that allows to view single
> instances as traversables with a single member then I must look
really
> carefully at the TraversableLike trait and watch out for all
methods that
> should be handled differently. For example TraversableLike
implements the
> isEmpty method by:
>
> def isEmpty: Boolean = {
> var result = true
> breakable {
> for (x <- this) {
> result = false
> break
> }
> }
> result
> }
>
> Clearly, a "SingleTraversable" can do better:
>
> override def isEmpty: Boolean = false
>
> If the TraversableLike trait changes in future I might miss some
of the
> methods that should be overriden and fallback on inefficient
> implementations.
>
> Therefore I think that it would be better to have pure abstract
collection
> traits that have to be implemented.
>
> Cheers,
>
> --Stefan
>
> PS: Is there more material available for the new 2.8 collections?
>
>
>
>
>
>
|
|
Re: Collections in 2.8: Why extends the collection traits their implementation traits (and not the other way round)?
You are approaching this problem without a full undertanding of what traits are.
Here are three ways of going about the problem:
1) Pure, rich interfaces (TraversableTemplate alone 66 methods). In this case, the likelyhood of people creating new collection types (outside libraries) is small, as there is just way too much methods to be implemented. Furthermore, most of these methods are likely to be implemented in the same way, which increased code duplication.
2) Pure, poor interfaces (think Java arrays). In this case, you may well implement your own collections, and you'll probably create many more methods on it. However, these methods will be created in an ad-hoc fashion, won't be available to consumers of the interface, you'll still have code duplication and, to top it all, you are unlikely to have as many methods as as provided in the other cases.
3) Rich traits. You get a rich interface and all of the methods will be available to its consumers. However, you are still likely to create new collections, as there are only a handful of methods that require implementation. Furthermore, you can override other methods for optimization, but, if you don't, you still get methods no worse than most other collections.
You see a problem in that you may get sub-optimal methods. I see a problem in not getting those methods at all, or not being able to use them on consumers of the interface.
Another possibility would be pure interfaces plus traits, but one has to ask what is gained by that?
On Thu, Oct 22, 2009 at 6:32 AM, Stefan Wachter <Stefan.Wachter@...> wrote:
Hi all,
I took a closer look on the collections in 2.8 and read the SID for collections (http://www.scala-lang.org/sids).
Having my (basic) OO knowledge in mind I expected to find pure abstract traits (i.e. interfaces) that describe the basic kinds of collections. Then these interfaces would be implemented somehow.
Yet, what I found were traits that stand for certain collection concepts (like Traversable or Iterable) that inherit lots of implementation code from so called template traits (named TraversableLike or IterableLike, respectively) and do not add any further aspects.
I think that this design can make custom implementations of collections more difficult.
For example if I want to develop a trait that allows to view single instances as traversables with a single member then I must look really carefully at the TraversableLike trait and watch out for all methods that should be handled differently. For example TraversableLike implements the isEmpty method by:
def isEmpty: Boolean = {
var result = true
breakable {
for (x <- this) {
result = false
break
}
}
result
}
Clearly, a "SingleTraversable" can do better:
override def isEmpty: Boolean = false
If the TraversableLike trait changes in future I might miss some of the methods that should be overriden and fallback on inefficient implementations.
Therefore I think that it would be better to have pure abstract collection traits that have to be implemented.
Cheers,
--Stefan
PS: Is there more material available for the new 2.8 collections?
-- Daniel C. Sobral Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.
|
|
Re: Collections in 2.8: Why extends the collection traits their implementation traits (and not the other way round)?
Hi Daniel,
I agree that richness is the goal. But this can be achieved by rich
interfaces (i.e. traits without implementations) at the top of the
hierarchy without the disadvantages you mention:
The implementation burden of these interfaces can be minimized by
"template traits" that an implementor can mixin as needed. By offering
suitable template traits there would be little or no code duplication.
For example if you want to implement a new Traversable and you are fine
with the implementation of the current TraversableLike (former
TraversableTemplate) then just mix it in! The Scala collection library
could offer other mixins that are more granular that ease
implementation (e.g. define flatMap based on map and flatten, ...).
This solution has:
1. No disadvantage for the end user -> you have a rich interface
2. An advantage for the library writer -> you can decide yourself
which implementations you want to inherit
Cheers,
--Stefan
Daniel Sobral wrote:
You are approaching this problem without a full undertanding of
what traits are.
Here are three ways of going about the problem:
1) Pure, rich interfaces (TraversableTemplate alone 66 methods).
In this case, the likelyhood of people creating new collection types
(outside libraries) is small, as there is just way too much methods to
be implemented. Furthermore, most of these methods are likely to be
implemented in the same way, which increased code duplication.
2) Pure, poor interfaces (think Java arrays). In this case, you
may well implement your own collections, and you'll probably create
many more methods on it. However, these methods will be created in an
ad-hoc fashion, won't be available to consumers of the interface,
you'll still have code duplication and, to top it all, you are unlikely
to have as many methods as as provided in the other cases.
3) Rich traits. You get a rich interface and all of the methods
will be available to its consumers. However, you are still likely to
create new collections, as there are only a handful of methods that
require implementation. Furthermore, you can override other methods for
optimization, but, if you don't, you still get methods no worse than
most other collections.
You see a problem in that you may get sub-optimal methods. I see
a problem in not getting those methods at all, or not being able to use
them on consumers of the interface.
Another possibility would be pure interfaces plus traits, but
one has to ask what is gained by that?
On Thu, Oct 22, 2009 at 6:32 AM, Stefan
Wachter <Stefan.Wachter@...>
wrote:
Hi all,
I took a closer look on the collections in 2.8 and read the SID for
collections (http://www.scala-lang.org/sids).
Having my (basic) OO knowledge in mind I expected to find pure abstract
traits (i.e. interfaces) that describe the basic kinds of collections.
Then these interfaces would be implemented somehow.
Yet, what I found were traits that stand for certain collection
concepts (like Traversable or Iterable) that inherit lots of
implementation code from so called template traits (named
TraversableLike or IterableLike, respectively) and do not add any
further aspects.
I think that this design can make custom implementations of collections
more difficult.
For example if I want to develop a trait that allows to view single
instances as traversables with a single member then I must look really
carefully at the TraversableLike trait and watch out for all methods
that should be handled differently. For example TraversableLike
implements the isEmpty method by:
def isEmpty: Boolean = {
var result = true
breakable {
for (x <- this) {
result = false
break
}
}
result
}
Clearly, a "SingleTraversable" can do better:
override def isEmpty: Boolean = false
If the TraversableLike trait changes in future I might miss some of the
methods that should be overriden and fallback on inefficient
implementations.
Therefore I think that it would be better to have pure abstract
collection traits that have to be implemented.
Cheers,
--Stefan
PS: Is there more material available for the new 2.8 collections?
--
Daniel C. Sobral
Something I learned in academia: there are three kinds of academic
reviews: review by name, review by reference and review by value.
|
|
Re: Collections in 2.8: Why extends the collection traits their implementation traits (and not the other way round)?
But you _can_ decide which implementations you want to inherit, by the simple artifact of overriding them. This gives you a better granularity than any other alternative. So the question is, what is the disadvantage of going the override way?
On Thu, Oct 22, 2009 at 10:53 AM, Stefan Wachter <Stefan.Wachter@...> wrote:
Hi Daniel, I agree that richness is the goal. But this can be achieved by rich interfaces (i.e. traits without implementations) at the top of the hierarchy without the disadvantages you mention:
The implementation burden of these interfaces can be minimized by "template traits" that an implementor can mixin as needed. By offering suitable template traits there would be little or no code duplication. For example if you want to implement a new Traversable and you are fine with the implementation of the current TraversableLike (former TraversableTemplate) then just mix it in! The Scala collection library could offer other mixins that are more granular that ease implementation (e.g. define flatMap based on map and flatten, ...).
This solution has: 1. No disadvantage for the end user -> you have a rich interface 2. An advantage for the library writer -> you can decide yourself which implementations you want to inherit Cheers,
--Stefan
Daniel Sobral wrote:
You are approaching this problem without a full undertanding of what traits are.
Here are three ways of going about the problem:
1) Pure, rich interfaces (TraversableTemplate alone 66 methods). In this case, the likelyhood of people creating new collection types (outside libraries) is small, as there is just way too much methods to be implemented. Furthermore, most of these methods are likely to be implemented in the same way, which increased code duplication.
2) Pure, poor interfaces (think Java arrays). In this case, you may well implement your own collections, and you'll probably create many more methods on it. However, these methods will be created in an ad-hoc fashion, won't be available to consumers of the interface, you'll still have code duplication and, to top it all, you are unlikely to have as many methods as as provided in the other cases.
3) Rich traits. You get a rich interface and all of the methods will be available to its consumers. However, you are still likely to create new collections, as there are only a handful of methods that require implementation. Furthermore, you can override other methods for optimization, but, if you don't, you still get methods no worse than most other collections.
You see a problem in that you may get sub-optimal methods. I see a problem in not getting those methods at all, or not being able to use them on consumers of the interface.
Another possibility would be pure interfaces plus traits, but one has to ask what is gained by that?
On Thu, Oct 22, 2009 at 6:32 AM, Stefan Wachter <Stefan.Wachter@...> wrote:
Hi all,
I took a closer look on the collections in 2.8 and read the SID for collections (http://www.scala-lang.org/sids).
Having my (basic) OO knowledge in mind I expected to find pure abstract traits (i.e. interfaces) that describe the basic kinds of collections. Then these interfaces would be implemented somehow.
Yet, what I found were traits that stand for certain collection concepts (like Traversable or Iterable) that inherit lots of implementation code from so called template traits (named TraversableLike or IterableLike, respectively) and do not add any further aspects.
I think that this design can make custom implementations of collections more difficult.
For example if I want to develop a trait that allows to view single instances as traversables with a single member then I must look really carefully at the TraversableLike trait and watch out for all methods that should be handled differently. For example TraversableLike implements the isEmpty method by:
def isEmpty: Boolean = {
var result = true
breakable {
for (x <- this) {
result = false
break
}
}
result
}
Clearly, a "SingleTraversable" can do better:
override def isEmpty: Boolean = false
If the TraversableLike trait changes in future I might miss some of the methods that should be overriden and fallback on inefficient implementations.
Therefore I think that it would be better to have pure abstract collection traits that have to be implemented.
Cheers,
--Stefan
PS: Is there more material available for the new 2.8 collections?
--
Daniel C. Sobral
Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.
-- Daniel C. Sobral Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.
|
|
Re: Collections in 2.8: Why extends the collection traits their implementation traits (and not the other way round)?
Mind you, it probably wouldn't hurt to have an abstract trait
containing just map, flatMap and foreach
Someone's going to reply now and point out that it already exists :)
On Thu, Oct 22, 2009 at 1:53 PM, Stefan Wachter < Stefan.Wachter@...> wrote:
> Hi Daniel,
>
> I agree that richness is the goal. But this can be achieved by rich
> interfaces (i.e. traits without implementations) at the top of the hierarchy
> without the disadvantages you mention:
>
> The implementation burden of these interfaces can be minimized by "template
> traits" that an implementor can mixin as needed. By offering suitable
> template traits there would be little or no code duplication. For example if
> you want to implement a new Traversable and you are fine with the
> implementation of the current TraversableLike (former TraversableTemplate)
> then just mix it in! The Scala collection library could offer other mixins
> that are more granular that ease implementation (e.g. define flatMap based
> on map and flatten, ...).
>
> This solution has:
>
> 1. No disadvantage for the end user -> you have a rich interface
> 2. An advantage for the library writer -> you can decide yourself which
> implementations you want to inherit
>
> Cheers,
>
> --Stefan
>
>
> Daniel Sobral wrote:
>
> You are approaching this problem without a full undertanding of what traits
> are.
>
> Here are three ways of going about the problem:
>
> 1) Pure, rich interfaces (TraversableTemplate alone 66 methods). In this
> case, the likelyhood of people creating new collection types (outside
> libraries) is small, as there is just way too much methods to be
> implemented. Furthermore, most of these methods are likely to be implemented
> in the same way, which increased code duplication.
>
> 2) Pure, poor interfaces (think Java arrays). In this case, you may well
> implement your own collections, and you'll probably create many more methods
> on it. However, these methods will be created in an ad-hoc fashion, won't be
> available to consumers of the interface, you'll still have code duplication
> and, to top it all, you are unlikely to have as many methods as as provided
> in the other cases.
>
> 3) Rich traits. You get a rich interface and all of the methods will be
> available to its consumers. However, you are still likely to create new
> collections, as there are only a handful of methods that require
> implementation. Furthermore, you can override other methods for
> optimization, but, if you don't, you still get methods no worse than most
> other collections.
>
> You see a problem in that you may get sub-optimal methods. I see a problem
> in not getting those methods at all, or not being able to use them on
> consumers of the interface.
>
> Another possibility would be pure interfaces plus traits, but one has to ask
> what is gained by that?
> On Thu, Oct 22, 2009 at 6:32 AM, Stefan Wachter < Stefan.Wachter@...>
> wrote:
>>
>> Hi all,
>>
>> I took a closer look on the collections in 2.8 and read the SID for
>> collections ( http://www.scala-lang.org/sids).
>>
>> Having my (basic) OO knowledge in mind I expected to find pure abstract
>> traits (i.e. interfaces) that describe the basic kinds of collections. Then
>> these interfaces would be implemented somehow.
>>
>> Yet, what I found were traits that stand for certain collection concepts
>> (like Traversable or Iterable) that inherit lots of implementation code from
>> so called template traits (named TraversableLike or IterableLike,
>> respectively) and do not add any further aspects.
>>
>> I think that this design can make custom implementations of collections
>> more difficult.
>>
>> For example if I want to develop a trait that allows to view single
>> instances as traversables with a single member then I must look really
>> carefully at the TraversableLike trait and watch out for all methods that
>> should be handled differently. For example TraversableLike implements the
>> isEmpty method by:
>>
>> def isEmpty: Boolean = {
>> var result = true
>> breakable {
>> for (x <- this) {
>> result = false
>> break
>> }
>> }
>> result
>> }
>>
>> Clearly, a "SingleTraversable" can do better:
>>
>> override def isEmpty: Boolean = false
>>
>> If the TraversableLike trait changes in future I might miss some of the
>> methods that should be overriden and fallback on inefficient
>> implementations.
>>
>> Therefore I think that it would be better to have pure abstract collection
>> traits that have to be implemented.
>>
>> Cheers,
>>
>> --Stefan
>>
>> PS: Is there more material available for the new 2.8 collections?
>>
>
>
>
> --
> Daniel C. Sobral
>
> Something I learned in academia: there are three kinds of academic reviews:
> review by name, review by reference and review by value.
>
>
|
|
Re: Collections in 2.8: Why extends the collection traits their implementation traits (and not the other way round)?
On Thu, Oct 22, 2009 at 3:23 PM, Kevin Wright <kev.lee.wright@...> wrote:
Mind you, it probably wouldn't hurt to have an abstract trait
containing just map, flatMap and foreach
Someone's going to reply now and point out that it already exists :)
50 cent says it'll be Tony Morris
On Thu, Oct 22, 2009 at 1:53 PM, Stefan Wachter < Stefan.Wachter@...> wrote:
> Hi Daniel,
>
> I agree that richness is the goal. But this can be achieved by rich
> interfaces (i.e. traits without implementations) at the top of the hierarchy
> without the disadvantages you mention:
>
> The implementation burden of these interfaces can be minimized by "template
> traits" that an implementor can mixin as needed. By offering suitable
> template traits there would be little or no code duplication. For example if
> you want to implement a new Traversable and you are fine with the
> implementation of the current TraversableLike (former TraversableTemplate)
> then just mix it in! The Scala collection library could offer other mixins
> that are more granular that ease implementation (e.g. define flatMap based
> on map and flatten, ...).
>
> This solution has:
>
> 1. No disadvantage for the end user -> you have a rich interface
> 2. An advantage for the library writer -> you can decide yourself which
> implementations you want to inherit
>
> Cheers,
>
> --Stefan
>
>
> Daniel Sobral wrote:
>
> You are approaching this problem without a full undertanding of what traits
> are.
>
> Here are three ways of going about the problem:
>
> 1) Pure, rich interfaces (TraversableTemplate alone 66 methods). In this
> case, the likelyhood of people creating new collection types (outside
> libraries) is small, as there is just way too much methods to be
> implemented. Furthermore, most of these methods are likely to be implemented
> in the same way, which increased code duplication.
>
> 2) Pure, poor interfaces (think Java arrays). In this case, you may well
> implement your own collections, and you'll probably create many more methods
> on it. However, these methods will be created in an ad-hoc fashion, won't be
> available to consumers of the interface, you'll still have code duplication
> and, to top it all, you are unlikely to have as many methods as as provided
> in the other cases.
>
> 3) Rich traits. You get a rich interface and all of the methods will be
> available to its consumers. However, you are still likely to create new
> collections, as there are only a handful of methods that require
> implementation. Furthermore, you can override other methods for
> optimization, but, if you don't, you still get methods no worse than most
> other collections.
>
> You see a problem in that you may get sub-optimal methods. I see a problem
> in not getting those methods at all, or not being able to use them on
> consumers of the interface.
>
> Another possibility would be pure interfaces plus traits, but one has to ask
> what is gained by that?
> On Thu, Oct 22, 2009 at 6:32 AM, Stefan Wachter < Stefan.Wachter@...>
> wrote:
>>
>> Hi all,
>>
>> I took a closer look on the collections in 2.8 and read the SID for
>> collections ( http://www.scala-lang.org/sids).
>>
>> Having my (basic) OO knowledge in mind I expected to find pure abstract
>> traits (i.e. interfaces) that describe the basic kinds of collections. Then
>> these interfaces would be implemented somehow.
>>
>> Yet, what I found were traits that stand for certain collection concepts
>> (like Traversable or Iterable) that inherit lots of implementation code from
>> so called template traits (named TraversableLike or IterableLike,
>> respectively) and do not add any further aspects.
>>
>> I think that this design can make custom implementations of collections
>> more difficult.
>>
>> For example if I want to develop a trait that allows to view single
>> instances as traversables with a single member then I must look really
>> carefully at the TraversableLike trait and watch out for all methods that
>> should be handled differently. For example TraversableLike implements the
>> isEmpty method by:
>>
>> def isEmpty: Boolean = {
>> var result = true
>> breakable {
>> for (x <- this) {
>> result = false
>> break
>> }
>> }
>> result
>> }
>>
>> Clearly, a "SingleTraversable" can do better:
>>
>> override def isEmpty: Boolean = false
>>
>> If the TraversableLike trait changes in future I might miss some of the
>> methods that should be overriden and fallback on inefficient
>> implementations.
>>
>> Therefore I think that it would be better to have pure abstract collection
>> traits that have to be implemented.
>>
>> Cheers,
>>
>> --Stefan
>>
>> PS: Is there more material available for the new 2.8 collections?
>>
>
>
>
> --
> Daniel C. Sobral
>
> Something I learned in academia: there are three kinds of academic reviews:
> review by name, review by reference and review by value.
>
>
-- Viktor Klang | "A complex system that works is invariably | found to have evolved from a simple system | that worked." - John Gall
Blog: klangism.blogspot.comTwttr: viktorklang Code: github.com/viktorklang
|
|
Re: Collections in 2.8: Why extends the collection traits their implementation traits (and not the other way round)?
The disadvantage of the "override way" is that I might miss some
overrides and do not get informed by the compiler (as mentioned in my
original post). It is frightening to implement a class that has to
override about 70 method (or maybe only 55 really have to be
overriddden)!
Daniel Sobral wrote:
But you _can_ decide which implementations you want to
inherit, by the simple artifact of overriding them. This gives you a
better granularity than any other alternative. So the question is, what
is the disadvantage of going the override way?
On Thu, Oct 22, 2009 at 10:53 AM, Stefan
Wachter <Stefan.Wachter@...>
wrote:
Hi Daniel,
I agree that richness is the goal. But this can be achieved by rich
interfaces (i.e. traits without implementations) at the top of the
hierarchy without the disadvantages you mention:
The implementation burden of these interfaces can be minimized by
"template traits" that an implementor can mixin as needed. By offering
suitable template traits there would be little or no code duplication.
For example if you want to implement a new Traversable and you are fine
with the implementation of the current TraversableLike (former
TraversableTemplate) then just mix it in! The Scala collection library
could offer other mixins that are more granular that ease
implementation (e.g. define flatMap based on map and flatten, ...).
This solution has:
1. No disadvantage for the end user -> you have a rich interface
2. An advantage for the library writer -> you can decide yourself
which implementations you want to inherit
Cheers,
--Stefan
Daniel Sobral wrote:
You are approaching this problem without a full undertanding
of what traits are.
Here are three ways of going about the problem:
1) Pure, rich interfaces (TraversableTemplate alone 66
methods). In this case, the likelyhood of people creating new
collection types (outside libraries) is small, as there is just way too
much methods to be implemented. Furthermore, most of these methods are
likely to be implemented in the same way, which increased code
duplication.
2) Pure, poor interfaces (think Java arrays). In this case,
you may well implement your own collections, and you'll probably create
many more methods on it. However, these methods will be created in an
ad-hoc fashion, won't be available to consumers of the interface,
you'll still have code duplication and, to top it all, you are unlikely
to have as many methods as as provided in the other cases.
3) Rich traits. You get a rich interface and all of the
methods will be available to its consumers. However, you are still
likely to create new collections, as there are only a handful of
methods that require implementation. Furthermore, you can override
other methods for optimization, but, if you don't, you still get
methods no worse than most other collections.
You see a problem in that you may get sub-optimal methods. I
see a problem in not getting those methods at all, or not being able to
use them on consumers of the interface.
Another possibility would be pure interfaces plus traits,
but one has to ask what is gained by that?
On Thu, Oct 22, 2009 at 6:32 AM, Stefan
Wachter <Stefan.Wachter@...>
wrote:
Hi all,
I took a closer look on the collections in 2.8 and read the SID for
collections (http://www.scala-lang.org/sids).
Having my (basic) OO knowledge in mind I expected to find pure abstract
traits (i.e. interfaces) that describe the basic kinds of collections.
Then these interfaces would be implemented somehow.
Yet, what I found were traits that stand for certain collection
concepts (like Traversable or Iterable) that inherit lots of
implementation code from so called template traits (named
TraversableLike or IterableLike, respectively) and do not add any
further aspects.
I think that this design can make custom implementations of collections
more difficult.
For example if I want to develop a trait that allows to view single
instances as traversables with a single member then I must look really
carefully at the TraversableLike trait and watch out for all methods
that should be handled differently. For example TraversableLike
implements the isEmpty method by:
def isEmpty: Boolean = {
var result = true
breakable {
for (x <- this) {
result = false
break
}
}
result
}
Clearly, a "SingleTraversable" can do better:
override def isEmpty: Boolean = false
If the TraversableLike trait changes in future I might miss some of the
methods that should be overriden and fallback on inefficient
implementations.
Therefore I think that it would be better to have pure abstract
collection traits that have to be implemented.
Cheers,
--Stefan
PS: Is there more material available for the new 2.8 collections?
--
Daniel C. Sobral
Something I learned in academia: there are three kinds of academic
reviews: review by name, review by reference and review by value.
--
Daniel C. Sobral
Something I learned in academia: there are three kinds of academic
reviews: review by name, review by reference and review by value.
|
|
Re: Collections in 2.8: Why extends the collection traits their implementation traits (and not the other way round)?
On Thu, Oct 22, 2009 at 10:32:12AM +0200, Stefan Wachter wrote:
> Therefore I think that it would be better to have pure abstract
> collection traits that have to be implemented.
Although it does not exactly address your point, you can see the start
of my attempt to reverse engineer the interfaces:
http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk/src/library/scala/collection/interfaces/My own motivation was getting the compiler to assist in verifying that
the Proxy and Forwarder traits were proxying and forwarding all the
methods they're supposed to.
On Thu, Oct 22, 2009 at 02:23:01PM +0100, Kevin Wright wrote:
> Mind you, it probably wouldn't hurt to have an abstract trait
> containing just map, flatMap and foreach
>
> Someone's going to reply now and point out that it already exists :)
https://lampsvn.epfl.ch/trac/scala/ticket/676"Create trait for things that are comprehendable"
However I've tried to do this a couple times and it is trickier (and
more of a moving target) than it appears.
--
Paul Phillips | The important thing here is that the music is not in
In Theory | the piano. And knowledge and edification is not in the
Empiricist | computer. The computer is simply an instrument whose
ha! spill, pupil | music is ideas. -- Alan Kay
|
|
Re: Collections in 2.8: Why extends the collection traits their implementation traits (and not the other way round)?
On Thu, Oct 22, 2009 at 2:57 PM, Paul Phillips < paulp@...> wrote:
> On Thu, Oct 22, 2009 at 10:32:12AM +0200, Stefan Wachter wrote:
>> Therefore I think that it would be better to have pure abstract
>> collection traits that have to be implemented.
>
> Although it does not exactly address your point, you can see the start
> of my attempt to reverse engineer the interfaces:
>
> http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk/src/library/scala/collection/interfaces/>
> My own motivation was getting the compiler to assist in verifying that
> the Proxy and Forwarder traits were proxying and forwarding all the
> methods they're supposed to.
>
> On Thu, Oct 22, 2009 at 02:23:01PM +0100, Kevin Wright wrote:
>> Mind you, it probably wouldn't hurt to have an abstract trait
>> containing just map, flatMap and foreach
>>
>> Someone's going to reply now and point out that it already exists :)
>
> https://lampsvn.epfl.ch/trac/scala/ticket/676> "Create trait for things that are comprehendable"
>
> However I've tried to do this a couple times and it is trickier (and
> more of a moving target) than it appears.
Yikes! I see what you mean. Though I do like Mile's proposal for 2.8...
One question: shouldn't the trait be comprehensible, instead of comprehendable?
> --
> Paul Phillips | The important thing here is that the music is not in
> In Theory | the piano. And knowledge and edification is not in the
> Empiricist | computer. The computer is simply an instrument whose
> ha! spill, pupil | music is ideas. -- Alan Kay
>
|
|
Re: Collections in 2.8: Why extends the collection traits their implementation traits (and not the other way round)?
On Thu, Oct 22, 2009 at 03:13:32PM +0100, Kevin Wright wrote:
> One question: shouldn't the trait be comprehensible, instead of
> comprehendable?
Yes.
--
Paul Phillips | A Sunday school is a prison in which children do
Moral Alien | penance for the evil conscience of their parents.
Empiricist | -- H. L. Mencken
i pull his palp! |----------* http://www.improving.org/paulp/ *----------
|
|
Re: Collections in 2.8: Why extends the collection traits their implementation traits (and not the other way round)?
Hi Paul,
these interfaces are exactly what I was looking for! I did not come
across them because the scala.collection traits do not extend them. Are
there plans to do so? These interfaces should be at the top of the
collection hierarchy and usage of collections should really on them!
Cheers,
--Stefan
Paul Phillips wrote:
On Thu, Oct 22, 2009 at 10:32:12AM +0200, Stefan Wachter wrote:
Therefore I think that it would be better to have pure abstract
collection traits that have to be implemented.
Although it does not exactly address your point, you can see the start
of my attempt to reverse engineer the interfaces:
http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk/src/library/scala/collection/interfaces/
My own motivation was getting the compiler to assist in verifying that
the Proxy and Forwarder traits were proxying and forwarding all the
methods they're supposed to.
On Thu, Oct 22, 2009 at 02:23:01PM +0100, Kevin Wright wrote:
Mind you, it probably wouldn't hurt to have an abstract trait
containing just map, flatMap and foreach
Someone's going to reply now and point out that it already exists :)
https://lampsvn.epfl.ch/trac/scala/ticket/676
"Create trait for things that are comprehendable"
However I've tried to do this a couple times and it is trickier (and
more of a moving target) than it appears.
|
|
Re: Collections in 2.8: Why extends the collection traits their implementation traits (and not the other way round)?
On Thu, Oct 22, 2009 at 04:39:44PM +0200, Stefan Wachter wrote:
> these interfaces are exactly what I was looking for! I did not come
> across them because the scala.collection traits do not extend them.
> Are there plans to do so? These interfaces should be at the top of the
> collection hierarchy and usage of collections should really on them!
It's my own little project so I can't say there are reliable plans for
them, but I agree with you that there's a benefit, so they'll make their
way in eventually if martin approves.
--
Paul Phillips | It's better to have gloved and tossed than never to
Caged Spirit | have played baseball.
Empiricist |
pal, i pill push |----------* http://www.improving.org/paulp/ *----------
|
|
Re: Collections in 2.8: Why extends the collection traits their implementation traits (and not the other way round)?
(1) and (3) aren't mutually exclusive. The library designer can create traits that contain no implementation, and then provide a parallel tree to mixins the provide base implementations. I think design wise this is a better approach, but it's a lot more work for the library writer.
On Thu, Oct 22, 2009 at 8:14 AM, Daniel Sobral <dcsobral@...> wrote:
You are approaching this problem without a full undertanding of what traits are.
Here are three ways of going about the problem:
1) Pure, rich interfaces (TraversableTemplate alone 66 methods). In this case, the likelyhood of people creating new collection types (outside libraries) is small, as there is just way too much methods to be implemented. Furthermore, most of these methods are likely to be implemented in the same way, which increased code duplication.
2) Pure, poor interfaces (think Java arrays). In this case, you may well implement your own collections, and you'll probably create many more methods on it. However, these methods will be created in an ad-hoc fashion, won't be available to consumers of the interface, you'll still have code duplication and, to top it all, you are unlikely to have as many methods as as provided in the other cases.
3) Rich traits. You get a rich interface and all of the methods will be available to its consumers. However, you are still likely to create new collections, as there are only a handful of methods that require implementation. Furthermore, you can override other methods for optimization, but, if you don't, you still get methods no worse than most other collections.
You see a problem in that you may get sub-optimal methods. I see a problem in not getting those methods at all, or not being able to use them on consumers of the interface.
Another possibility would be pure interfaces plus traits, but one has to ask what is gained by that?
Hi all,
I took a closer look on the collections in 2.8 and read the SID for collections (http://www.scala-lang.org/sids).
Having my (basic) OO knowledge in mind I expected to find pure abstract traits (i.e. interfaces) that describe the basic kinds of collections. Then these interfaces would be implemented somehow.
Yet, what I found were traits that stand for certain collection concepts (like Traversable or Iterable) that inherit lots of implementation code from so called template traits (named TraversableLike or IterableLike, respectively) and do not add any further aspects.
I think that this design can make custom implementations of collections more difficult.
For example if I want to develop a trait that allows to view single instances as traversables with a single member then I must look really carefully at the TraversableLike trait and watch out for all methods that should be handled differently. For example TraversableLike implements the isEmpty method by:
def isEmpty: Boolean = {
var result = true
breakable {
for (x <- this) {
result = false
break
}
}
result
}
Clearly, a "SingleTraversable" can do better:
override def isEmpty: Boolean = false
If the TraversableLike trait changes in future I might miss some of the methods that should be overriden and fallback on inefficient implementations.
Therefore I think that it would be better to have pure abstract collection traits that have to be implemented.
Cheers,
--Stefan
PS: Is there more material available for the new 2.8 collections?
--
Daniel C. Sobral
Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.
-- http://erikengbrecht.blogspot.com/
|
