Sorry for re-posting this.
Has noone an idea about it?
> 2 issues:
>
> 1) old and new GPath
>
> assert this.class.methods*.name == this.class.methods.name
>
> Is the old syntax deprecated?
>
> 2) variable parameter lists
>
> def foo(*args){ println args[0] }
> foo(1,2,3)
>
> Is this intended to come?
>
> thanx
> Mittie
>
ok, I partly answer my own question(Continue reading)What's new about the spread-dot operator isn't really that you can use it with properties in a GPath. That is also possible without it. What's new is, that you can use it with method calls like this.class.methods*.foo() so the implementation docu is a bit misleading (see below). // SpreadDotTest.groovy // // Test for the spread dot operator "*." // For an example, // list*.property // equals to // list.collect { it?.property } I think it should be object*.reference equals to object.toList().collect{ item -> item?.reference } where reference can be a field access, a property access, a method call, or an expression. Not sure this is totally correct, though...
Dierk Koenig schrieb:
[...]
> I think it should be
>
> object*.reference
>
> equals to
>
> object.toList().collect{ item -> item?.reference }
the spread operator works only on lists and I think maps. Not sure if an
object is converted to a list when it's no list.
> where reference can be a field access, a property access, a method call,
> or an expression.
I am not sure about the expression.
bye blackdrag
hi blackdrag,
thanx for the answer. I have the same uncertainties and the
testcases don't reveal it.
I had a look at ScriptByteCodeAdapter
public static Object invokeMethodSpreadSafe(Object object, String
methodName, Object arguments) throws Throwable{
if (object != null) {
if (object instanceof List) {
List list = (List) object;
List answer = new ArrayList();
Iterator it = list.iterator();
for (; it.hasNext();) {
answer.add(invokeMethodSafe(it.next(), methodName,
arguments));
}
return answer;
}
else
return invokeMethodSafe(object, methodName, arguments);
}
return null;
Hm, but beside the implementation, how is it _supposed_ to work?
(Therefore the discussion on the JSR list)
cheers
Mittie
(Continue reading)
oops, sorry. I was to quick in sending. The handling is of course different for the spread operator on maps and list and the spread-dot operator for method calls. cheers Mittie > -----Original Message----- > From: Dierk Koenig [mailto:dierk.koenig@...] > Sent: Freitag, 1. Juli 2005 16:58 > To: jsr@... > Subject: RE: [groovy-jsr] spread operator issues > > > hi blackdrag, > > thanx for the answer. I have the same uncertainties and the > testcases don't reveal it. > > I had a look at ScriptByteCodeAdapter > public static Object invokeMethodSpreadSafe(Object object, String > methodName, Object arguments) throws Throwable{ > if (object != null) { > if (object instanceof List) { > List list = (List) object; > List answer = new ArrayList(); > Iterator it = list.iterator(); > for (; it.hasNext();) {(Continue reading)
Hi, A new version is available for download through IntelliJ IDEA's plug-in manager. Change log: - Adds support for IDEA 5.0 builds #3397 and #3401 which feature word completion in files of any given type! - Updates the default Groovy runtime to the latest snapshot of the forthcoming Groovy JSR-03 release Bug fixes: - GROOVY-941: GroovyJ does not report the file that compilation errors occur within and you can't click on them to jump to the line - GROOVY-948: GroovyJ breaks the "Colors and Fonts" panel in global settings Known issues: - GROOVY-939: GroovyJ compiles scripts using IDEA's JDK instead of the project/module's JDK See http://groovy.codehaus.org/IntelliJ+IDEA+Plugin and http://groovy.codehaus.org/GroovyJ+Status for details. Regards, Franck
Hi, developers,
We should make a decision whether groovy supports coercion convertion from List to Array in method invocation.
Below is the source code in MetaClass:
protected MetaMethod pickMethod(Object object, String methodName, Object[] arguments) {
MetaMethod method = null;
List methods = getMethods(methodName);
if (!methods.isEmpty()) {
Class[] argClasses = convertToTypeArray(arguments);
method = (MetaMethod) chooseMethod(methodName, methods, argClasses, true);
if (method == null) {
int size = (arguments != null) ? arguments.length : 0;
if (size == 1) {
Object firstArgument = arguments[0];
if (firstArgument instanceof List) {
// lets coerce the list arguments into an array of
// arguments
// e.g. calling JFrame.setLocation( [100, 100] )
List list = (List) firstArgument;
arguments = list.toArray();
argClasses = convertToTypeArray(arguments);
method = (MetaMethod) chooseMethod(methodName, methods, argClasses, true);
if (method==null) return null;
return new TransformMetaMethod(method) {
public Object invoke(Object object, Object[] arguments) throws Exception {
Object firstArgument = arguments[0];
List list = (List) firstArgument;
arguments = list.toArray();
return super.invoke(object, arguments);
}
(Continue reading)
Hiall, a) provide an own Groovy Stack(-trace) most of the time, the Java Stacktrace is pretty useless for the Groovy programmer as it contains lots of "invokeMethod" calls but you cannot see the sequence of groovy method calls easily. How about managing our own stack, e.g. inside MetaClass? This could be used for nice Stacktraces but also for Logging-, Tracing-, Profiling-, and Debugging-Support. b) allow isTrue() analogous to isCase() isCase() allows objects to decide how they work in the switch conditional. It would be parallel to also allow them control over the general boolean test. c) provide onMethodMissing(name, params) to allow objects to more conveniently implement Decorators, Adapters, etc. (even methods like curry() with arbitrary parameter length, hehe). Default would be implemented in Object and throws MissingMethodException. any opinions? cheers Mittie
Hi, On 21/07/05, Dierk Koenig <dierk.koenig@...> wrote: > a) provide an own Groovy Stack(-trace) > most of the time, the Java Stacktrace is pretty useless > for the Groovy programmer as it contains lots of > "invokeMethod" calls but you cannot see the sequence > of groovy method calls easily. How about managing our > own stack, e.g. inside MetaClass? > This could be used for nice Stacktraces but also for > Logging-, Tracing-, Profiling-, and Debugging-Support. That's an interesting idea. We need to see if that's possible. Moreover, we have to make sure we're creating those custom stacktraces lazily, since that's pretty expansive to build AFAIK. > b) allow isTrue() analogous to isCase() > isCase() allows objects to decide how they > work in the switch conditional. It would be parallel to > also allow them control over the general boolean test. isTrue() is a pretty good idea, I like that! > c) provide onMethodMissing(name, params) > to allow objects to more conveniently implement Decorators, > Adapters, etc. (even methods like curry() with arbitrary > parameter length, hehe). Default would be implemented in > Object and throws MissingMethodException. In fact, our invokeMehtod() already intercepts non-existing methods.(Continue reading)
Dierk Koenig schrieb: > Hiall, > > a) provide an own Groovy Stack(-trace) > most of the time, the Java Stacktrace is pretty useless > for the Groovy programmer as it contains lots of > "invokeMethod" calls but you cannot see the sequence > of groovy method calls easily. How about managing our > own stack, e.g. inside MetaClass? > This could be used for nice Stacktraces but also for > Logging-, Tracing-, Profiling-, and Debugging-Support. Problem: handling of non groovy classes not part of the runtime > b) allow isTrue() analogous to isCase() > isCase() allows objects to decide how they > work in the switch conditional. It would be parallel to > also allow them control over the general boolean test. I think that's a very good idea > c) provide onMethodMissing(name, params) > to allow objects to more conveniently implement Decorators, > Adapters, etc. (even methods like curry() with arbitrary > parameter length, hehe). Default would be implemented in > Object and throws MissingMethodException. as MrG said, invokeMethod can handle this. I want to limit the usage of invokeMethod to the really needed cases to enable more compiler checks(Continue reading)
RSS Feed1 | |
|---|---|
1 | |
1 | |
6 | |
1 | |
4 | |
1 | |
1 | |
2 | |
2 | |
1 | |
3 | |
22 | |
15 | |
5 | |
6 | |
17 | |
16 | |
105 | |
2 | |
30 | |
8 | |
85 | |
108 | |
11 | |
3 | |
44 | |
34 | |
51 | |
119 | |
208 | |
202 | |
46 | |
26 | |
137 | |
28 | |
104 | |
2 | |
79 | |
6 | |
1 |
