The basic motivation for this library is to provide extra utilities for inspecting and manipulating objects in the Scala REPL. I frequently find myself spending long periods in the REPL, poking at objects of poorly documented classes to see what they do and what data they contain.
Download the jar or build from source: https://bitbucket.org/eengbrec/scala-repl-utils/downloads/replutils_2.8.1-0.1.jar
There are three basic ways to use REPL Utils:
- Explicitly add the jar to the classpath when you launch the Scala interpretter
- Place the jar in $SCALA_HOME/lib
- Place a symbolic link to the jar in $SCALA_HOME/lib (useful if making modifications)
You could also globally add the jar to $CLASSPATH, but I don't recommend it.
There's currently only one useful function. It prints out the "attributes" of an object. The attributes are a subset of zero-arg methods. The filtering isn't very aggressive (I'll add criteria as I encounter problems), but it cuts out obvious problems like calling Object.wait and some of the noise generated by the Scala compiler. It currently does not print out fields because I haven't quite sorted out how to filter out compiler noise from real fields.
Here's example usage:
scala> import replutils._ import replutils._ scala> case class Test(a: CharSequence, b: Int) defined class Test scala> val t = Test("hello", 1) t: Test = Test(hello,1) scala> printAttrValues(t) hashCode: int = -229308731 b: int = 1 a: CharSequence (String) = hello productArity: int = 2 getClass: Class = class line0$object$$iw$$iw$Test
One thing you'll notice is that when the class of the object returned by a method is different from what's declared on the class (in this case, CharSequence versus String), it prints out both the declared class and the actual class. This is useful when dealing with APIs that frequently return objects that need to be downcast to more useful types, but fail to document this fact.
If you frequently find yourself poking at objects from poorly documented libraries, this is quite useful. However, one must be careful with objects that have side-effecting zero-arg methods, methods that are computationally intensive, and methods that return objects with large toString conversions.