The Artima Developer Community
Sponsored Link

Java Buzz Forum
Scala and Erasure

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Mathias Bogaert

Posts: 352
Nickname: pathos
Registered: Aug, 2003

Mathias Bogaert is a senior software architect at Intrasoft mainly doing projects for the EC.
Scala and Erasure Posted: Dec 19, 2012 5:10 AM
Reply to this message Reply

This post originated from an RSS feed registered with Java Buzz by Mathias Bogaert.
Original Post: Scala and Erasure
Feed Title: Scuttlebutt
Feed URL: http://feeds.feedburner.com/AtlassianDeveloperBlog
Feed Description: tech gossip by mathias
Latest Java Buzz Posts
Latest Java Buzz Posts by Mathias Bogaert
Latest Posts From Scuttlebutt

Advertisement
Mention generics to anyone who knows much about them and they’ll usually have an opinion on type reification and erasure. For the uninitiated, erasure is where a List of Strings (or a List parameterised by the String type) “forgets” that it has been parameterised by the String type once it has been compiled – ie. the type parameter is erased. Reification is the opposite, the type is remembered, or reified. Different platforms have different strategies for their generics implementations. For example C++ templates compile completely different bytes for vector<string> to vector<int>. Java on the other hand uses exactly the same byte-code for all implementations – underneath the covers it is just List<Object> – relying on the compiler to make sure the client code does the right thing (it also inserts the correct casts for you). There are many opinions on the relative merits of either approach, and erasure has much to recommend it, but erasure has a very specific draw-back: it doesn’t tell you at runtime what its actual type is. Not knowing the runtime type is usually not a problem, but very occasionally you need it. For instance, you sometimes want to construct an Array of your specific type T, and for that you need the specific Class<T> to do so. You cannot at runtime reconstruct the T[] without it*. Another example is a library that may need a representation of the type at runtime (usually via a Class instance, no longer a type but a type token) so it can do something with it, like look up a specific implementation from it. An example is in our page-objects library (a front-end testing library built upon WebDriver). To get a specific Page object you give it a Class<P extends Page> and it returns an instance of that page class: <P extends Page> P visit(Class<P> pageClass) {…} and use it: MyLoginPage page = app.visit(MyLoginPage.class) This last is quite handy, and very common in our tests but it does have some unnecessary duplication and boilerplate. Fortunately we can eliminate that in Scala. Scala has the ability to automagically produce values via implicit resolution. It also (in 2.8/2.9) has a feature known as Class Manifests. Using aManifest we create the following helper for the above: def goto[P <: Page: Manifest]: P =     app.visit(manifest[P].erasure.asInstanceOf[Class[P]]) this says, given some type parameter P that is a subtype of Page and has-a Manifest[P], call app.visit and pass the class instance that we implicitly summon (using manifest[P], a shorthand for implicitly[Manifest[P]]). Lastly (and unfortunately) we don’t in the type know the erased class’s type, but by construction we know it is correct so we cast using asInstanceOf[Class[P]]. We can now use this: val page = goto[MyLoginPage] // page is inferred to be of type MyLoginPage and we no longer need to pass the Class instance directly, we simply pass the type parameter! This would be of small value if it didn’t have a bunch of transitive benefits. You can build trees of related implicit dependencies (ie. they compose). You can use the pattern of having the related class (the Manifest in this case) provide type-specific behaviour, ie. the type-class pattern. So, using [...]

Read: Scala and Erasure

Topic: Yammer Metrics, A new way to monitor your application Previous Topic   Next Topic Topic: New Challenges for Enterprise Java


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us