Interesting - might be worth adding a helper method toReader() somewhere; not sure if it should go on Object or if it should be a helper method elsewhere?

Interesting stuff Corneil. We already support some basic type coercion mechanisms right now; like handling Enumeration / Iterator or arrays / collections and ints and Integer or GString and String.

Maybe we could go one step further and allow types to provide natural type coercion mechanisms.

e.g. we could add a method toType(Class) which would allow any type to offer its own type coercion mechanism to other types.

Then File, String, URL could all offer the ability to coerce themselves to an InputStream, Reader etc.

Then you could write a method

doSomething(Reader r)

and call it directly with a File, String, URL and so forth. (This would be neat!).

The one proviso with things like that is if you take a Reader / InputStream as a parameter you should always guarrentee to close it, whatever happens.

this feature is a little like auto-casting or auto-coercion. In dynamic method dispatch mode, this should happen by default.

In static typing mode a cast is probably gonna be required.

e.g.

String x = "hello"
doSomething((Reader) x)

While auto-coercion might be a little confusing, we've got heaps of helper methods now so if we all stick to Writer and Reader then we can do things like

doSomething(file.newReader())
doSomething(url.newReader())

etc

During the GroovyOne JSR meeting in London, we talked about using the "as" operator to provide a neater means to do that:

URL url = new URL("http://groovy.codehaus.org")
reader = url as Reader;
reader.readLine()

Now done using as type as indicated in comments.