Very nice examples but perhaps better to lose the reference to "LSP"
or make it clearer?
If the next line after setting res2 is: assert(res2.isInstanceOf[BitSet])
then I don't quite get substitutable behavior if I am expecting a BitSet.
LSP within certain bounds for sure but not blanket LSP.
Also, I am not sure what you mean by "100% safe". Perhaps you mean
statically type-checked according to the scala type system (which is what
you kind of say later in the same sentence - which I think sums it up nicely
and adequately).
Not trying to nit-pick. I just find type-safety to be a small subset of the
potentially desirable properties of programs. I would hate someone to
think that any program I wrote was "100% safe" just because it compiled
or met some type systems constraints.
Cheers, Paul.
On Thu, Nov 24, 2011 at 7:28 PM, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> I guess I missed the point in my (rather terse) example.
> What I was demonstrating is that the expression doesn't just change the
> contents of the collection, but also the type of the collection itself. For
> example:
> val bitSet = BitSet(1,2,3) //a BitSet can only hold integers, it subclasses
> Set[Int]
> val res1 = bitSet map {2*} //BitSet(2,4,6)
> val res2 = bitSet map {_.toString} //Set("1","2","3") BitSets can't hold
> strings, so returns a Set[String], as per the Liskov Substitution
> Principle.
> val myMap = Map(1 -> "x", 2 -> "y", 3 -> "z") //a Map[K,V] is also a
> collection of K->V pairs
> val res3 = myMap map {x => x._1.toString ->
> x._2} //Map("1"->"x","2"->"y","3"->"z"), a Map[String, String]
> val res4 = myMap map {case (a,b) => a.toString -> b} //more readable via
> pattern matching
> val res5 = myMap map {_._1} //List(1,2,3), a List[Int]
> val res6 = myMap map {_._2} //List("x","y","z"), a List[String]
> This is all 100% safe and statically typed, and is made possible by the
> "scary" CanBuildFrom implicit parameter that Stephen mention in his article.
> I don't believe that Fantom can do this, not least because it doesn't have
> highly-optimised collection types such as BitSet, it doesn't consider Maps
> to subclass collections of pairs, and it doesn't support creation of your
> own paramaterised collection types. So far as I'm aware, Scala is the only
> language in existence that directly supports such a scheme (though I imagine
> it would be totally possible to duplicate using something like Lisp macros)
> It looks threatening in the documentation, but when you actually use this
> stuff it's really quite effortless. The best part is that these collections
> are defined entirely in library code using completely standard syntax
> without a single line of compiler support required. Anybody could have
> implemented them without touching the compiler, and it's completely possible
> to implement your own collection types that fit transparently into this
> hierarchy (although you *do* have to understand the full method signatures
> at that point)
> 2011/11/24 Cédric Beust ♔ <ced...@beust.com>
>>
>> On Wed, Nov 23, 2011 at 3:05 PM, Kevin Wright <kev.lee.wri...@gmail.com>
>> wrote:
>>>
>>> They're also core to the mechanism that allows collections to just do the
>>> Right Thing(tm). For example:
>>> someBitSet map {_.toString}
>>
>> Right, but you can achieve the same result without needing implicits. I'll
>> just show how Fantom does it but I'm sure the same applies to
>> Gosu/Ceylon/Kotlin:
>> // a set of A instances, where A has a toUppercase method
>> aSet := [ A("foo"), A("bar") ]
>> l := aSet.map | v->Str | { v.toUppercase }
>> echo(l)
>> echo(l.typeof)
>> [FOO, BAR]
>> sys::Str[]
>> The signature of map() is exactly what you would expect: it takes a
>> function that takes an element of the collection and returns "something",
>> and the type of your expression is "list of something" (here we transformed
>> a list of A's into a list of strings).
>> It's really not rocket science, and the fact that you need implicits to
>> achieve this result is an implementation detail that's very specific to
>> Scala.
>> Sure, you can handwave it with "You don't need to understand the exact
>> details of the API", but the truth is... you really do. Not a week goes by
>> without me having to go check out a Javadoc or the signature of java.util or
>> Guava method. And saying that only library authors need to know about
>> implicits, CanBuildFrom and its triple generic signature is creating a rift
>> between the Scala developers (people who know and people who don't), which
>> is worrisome.
>
> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To post to this group, send email to javaposse@googlegroups.com.
> To unsubscribe from this group, send email to
> javaposse+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
