Re: documentation frustration

On 15 Apr 2004, at 18:55, bing ran wrote:
> James,
>
> Understanding that MetaClasses keep a list (a long list!) of methods  
> for
> a class and do dispatching from there,

Being a pedant for a moment, it actually keeps an efficient index based  
on method name & parameter numbers & types for fast lookups.

>  I also know  that all these
> methods have to be invoked with the help from the InvokerHelper, even
> for very naive things like this :
>
> 		String s = "a string"
> 		boolean c = s.contains("str");
> 		System.out.println(c);
>
>
> The generated bytecode is something equivalent to this:
>
>         String s = (String)InvokerHelper.asType("a string",
> java.lang.String.class);
>         Object aobj[] = {
>             "str"
>         };
>         Object obj = InvokerHelper.invokeMethod(s, "contains",  
> ((Object)
> (aobj)));
>         Object aobj1[] = {
>             obj
>         };
>
> InvokerHelper.invokeMethod(InvokerHelper.getProperty(java.lang.System.c 
> l
> ass, "out"), "println", ((Object) (aobj1)));
>
>
> Frankly I don't understand why all the trouble given the type
> information is all there.

Well if the method is being invoked on a statically typed variable  
(like 's' above) then its *meant* to do normal java static method  
dispatch. Its just we've not implemented that yet as this is just an  
optimisation. Functionally its identical.

>
> ...except for the contains() method. The contains() is not defined in
> the JDK but in GDK. The compiler does not know anything about that.

The groovy compiler knows about it. More later...

> So
> the bytecode wil basically go and try. Now suppose the GString class is
> a facade of String, I can define all the method extensions that can
> apply to String right there:
>
> class GString {
> 	String theDelegate;
> 	Boolean contains(String s) {...}
> }
>
> As a result. a few good things can happen:
>
> 1. The code editor now sees the new method so it can do code  
> completion,
> the lack of which is probably one of the major reason that writing Java
> is still a lot faster than writing Groovy.
> 2. The compiler can generate static function calls rather than go
> through MetaClass.
> 3. The performance improves.
> 4. Programmers can easily browser the code and know GDK extensions. I
> find myself using class browsing more than the JavaDoc for API help.
>
> Of course we lose here might  be a centralized place for method call
> interceptions. But consider that these classes are foundation classes  
> of
> the library and end users won't have much interest in doing such  
> things.
>
>
> Rather than just treating strings, lists, number as first-class
> citizens, Groovy may actually treat them as super citizens and generate
> fast code to use them.

I hear you. Right now GString is a delegate of String, however its not  
introspectable so that an IDE could auto-complete the methods. We need  
better support for this.

However for everything else other than the GString example you gave -  
e.g. for the 'contains' method on String, these methods are all  
introspectable via the MetaClass so any IDE which knows the type of  
something could give full name completion etc. i.e. all the new methods  
we've added to the JDK are all introspectable along with normal Java  
methods via the MetaClass.

James
-------
http://radio.weblogs.com/0112098/