jastrachan | 16 Apr 08:19 2004

Re: documentation frustration

On 15 Apr 2004, at 21:27, bing ran wrote
> I guess my point is I'd like to see:
> 1. to make  all the addon methods visible as early as possible in the
> development cycle, meaning to associate those extensions to the 
> "owners"
> in a static form: the class definition (or delegates of them), so that
> developers can see them; a java syntax aware code completion can see
> them (so that those extensions can actaully be used in java).

We cannot add methods to Object, Object[], Collection, Map, String, 
File so that they are available to Java.

We could build an entirely parallel object hierarchy (something that 
looks like a File, looks like an Object, looks like a String) but I 
don't see the value.

The aim of these new methods is to make Groovy code more groovy; we're 
pretty much stuck in Java-land with Java.

>  Sure a
> smart code completion tool can do the code completion, at a higher 
> cost.
> The thing is we can never optimize out  those dynamic dispatching as
> long as we depend on the metaclass and DefaultGroovyMethods to invoke
> those extensions.


i.e. if we're using static typing in Groovy we could absolutely 
optimise out the dynamic method dispatch and could generate static 
method dispatch bytecode just like Java does. e.g. to make a call to 
the static methods in DefaultGroovyMethods directly in bytecode.

> 2. The Inheritance and polymorphism doesn't seem to work well with the
> current scheme of extension. i.e., creating a method for a owner type
> does not automatically makes it avaible for subcalsses of the owner.

It does - inside Groovy at least. This works for both implementors of 
interfaces or for base classes. e.g. any Collection has methods like 
each(), findAll(), find(), any(), every() etc. Ditto any object has an 
'inspect()' method which returns a debug string of its fields

>  I
> might be wrong but I don't recall the generic logic. Static extension
> does not have this problem.

We are implementing 'static extension' conceptually. We're just not 
doing it by creating delegate types for the entire JDK.

e.g. imagine someone has FooCollection which implements Collection. 
We've added a load of groovy helper methods to GroovyCollection which 
is our delegate which wraps Collection and adds some new groovy methods 
- unfortunately FooCollection doesn't implement GroovyCollection so the 
new methods are not available.

By going with the delegate-wrapping approach we'd end up with lots of 
islands of objects that don't derive from our magic object hierarchy, 
so we'd have to start wrapping things everywhere - then this soon gets 
very complex when you have complex object graphs where things need to 
be wrapped as you navigate etc.

> 3.to avoid the exploding of the defaultGroovymethods and the static
> version of it. The Eclipse on my laptop basically pauses for  5 secs to
> open the java file.

Agreed - we need to refactor this into lots of little files. Though 
this is only an issue for implementors of Groovy - users of groovy 
don't need to know or care how we implement the new methods.