eird. Shouldn't it be superfluous in
this case?
Anyway, for the moment it seems it is resolved, althougth I regret to admit I
do not understand the mechanism which caused the problem nor the one which
fixed it at all.
Thanks,
OC
> which works without a glitch on my old computer (Java 1.7.0
ipt, which might get confusing for it
(sort of) creates those outside a, b and c for you automatically without you
having to declare it. Try it in a normal class, and you'll see the trick.
All the best,
OC
turning null, but
returning the result of the last expression in the closure -- precisely what I
would myself like to be available in future as "resultWith".
All the best,
OC
P.S. Perhaps "resultWith" or "resultTapping" would be even better than
"valueXXX".
On 8. 11. 2016, at 16:15, OC wrote:
> Hi there,
>
> as always I can be wrong, but I do not think it is possible to find a good
> name which (a) expresses the be
- 'valueTapping' as a modern equivalent of 'with' for the old functionality
or something like that.
All the best,
OC
On 8. 11. 2016, at 15:34, Paul King wrote:
> Hi everyone,
>
> We are hoping to release 2.5 not too far down the track. We are
> working on a reva
bug,
but triple alas, it is the intended behaviour, as shown in that thread :(
All the best,
OC
On 25. 8. 2016, at 17:54, John Smiljanic wrote:
> Groovy 2.4.6
>
> I am trying to override static property access/mutation in a groovy class.
> My objective is to read/write static
s like a pair
===
mmc.getAt={ index ->
...
}
mmc.getAt={ String index ->
...
}
===
does the job all right; thanks a big lot again!
All the best,
OC
g'}"].each { me[it] }
}
}
45 /tmp> groovy q
getAt 1
getAt 3.14
getProperty hi
getAt null
getAt class q
getProperty gstring
46 /tmp>
===
Thanks and all the best,
OC
s obvious
problems in the, ahem, let's say exciting, world driven by classloaders.
All the best and congrats you have found the culprit,
OC
On 13. 7. 2016, at 18:33, Scott Arnold wrote:
> Good news. I finally figured this out (mostly). It was an issue with dirty
> compiled code.
some " + icf.getClass()); // about the same in
Javaish
===
All the best,
OC
On 13. 7. 2016, at 17:01, Scott Arnold wrote:
> I'm new to Groovy (lots of Java experience but almost no Groovy experience)
> and maybe there is something very basic I am missing here, but I am runn
Jochen,
On 12. 7. 2016, at 12:43, Jochen Theodorou wrote:
> On 11.07.2016 23:26, OC wrote:
>> Hi there,
>>
>> with a pretty complex and heavily AST-transformed code, which, nevertheless,
>> *without typechecking builds and runs all right*, with a typechecker
&g
there is at
WideningCategories.java:237 might help; if not, well, I am afraid my report
would be good-for-nothing :(
Thanks and all the best,
OC
> On Tue, Jul 12, 2016 at 7:26 AM, OC wrote:
>> Hi there,
>>
>> with a pretty complex and heavily AST-transformed code, which, neverth
orm.ASTTransformationVisitor.visitClass(ASTTransformationVisitor.java:134)
at
org.codehaus.groovy.transform.ASTTransformationVisitor$2.call(ASTTransformationVisitor.java:178)
at
org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1053)
===
All the best,
OC
Jochen,
On 3. 4. 2016, at 22:29, Jochen Theodorou wrote:
> On 03.04.2016 17:33, OC wrote:
> [...]
>> ===
>> 6 /tmp> > class q {
>> static main(av) {
>>ExpandoMetaClass.enableGlobally()
>>Root.metaClass.static.propertyMissing={ name ->
Jochen,
On 3. 4. 2016, at 7:23, Jochen Theodorou wrote:
> On 01.04.2016 03:48, OC wrote:
>> playing with possibilities of the i/i pattern, I have found one can install
>> a static property to an interface, and then use the property all right --
>> see a proof-of-concept b
tested :)
Thanks and all the best,
OC
On 2. 4. 2016, at 19:19, Jochen Theodorou wrote:
> On 01.04.2016 21:38, OC wrote:
> [...]
>> ===
>> class Foo {
>> static instance=newInstance()
>> }
>> class Bar extends Foo {
>> static instance=newInstance()
>
).
Thanks and all the best,
OC
On 1. 4. 2016, at 11:48, Alessio Stalla wrote:
> Your requirement is logically inconsistent. If there is only one possible
> instance of Foo, there cannot be /another/ instance of Foo which is also a
> Bar.
>
> On 1 April 2016 at 04:28, OC wrote
ess method Foo.()V from class
Bar
at Bar.(qq.groovy)
at Bar.(qq.groovy)
at qq.run(qq.groovy:4)
87 /tmp>
===
What is the proper way to achieve this?
Thanks a lot,
OC
interfaces (which would otherwise not be possible without
exposing the implementation class), this is truly interesting.
The question is: can I rely on this rather arcane behaviour, that it will not
be broken in future Groovy versions?
Thanks,
OC
===
78 /tmp>
String getter=&
code instead of Eclipse, and thus I have to
squeeze the reports so that Xcode understands them. And the big advantage
(against the ASTT approach) would be no problem with traits :)
Thanks again a very big lot and all the best,
OC
ick in Groovy which makes this task groovier (or at the very
least reasonably manageable), or am I up to my own source preprocessor and/or
ASTTs (which again would clash with traits :/ )?
Thanks a lot,
OC
/post-process the method, nothing else. Its purpose is to make
it easier for programmer and faster runtime, but the functionality is precisely
the same[**].
Thanks and all the best,
OC
[*] On the other hand, the speed difference should not be that big if the
forwarding is done right, tha
er.someBarMethod() }
void anotherBarMethod(foo,bar,baz) { server.anotherBarMethod(foo,bar,baz) }
// and so forth
}
===
That's rather ugly solution compared with dynamic redirection (though it might
be much faster in the Java world, I did not benchmark it, but I can guess this
probably
Incidentally...
On 28. 3. 2016, at 18:10, OC wrote:
> completely absurd and very anti-object-oriented) “Cannot cast object”
> exception.
... this reminded me of a problem I so far haven't been able to find a proper
solution for: how the heck do you proxy in Groovy?
In ObjC,
annot cast object” exception.
That's precisely the terrible mess which causes Java to be one of the worst
languages for learning :(
All the best,
OC
On 28. 3. 2016, at 15:53, frenchy48 wrote:
> Thanks for replying
> as a side note OOP appear only in chapter 8 of my book so I have
hing Java-based ever might.
> now if you have a factory that returns the proper class and you assign it to
> a variable typed with a subclass it won't work.
===
26 /tmp> groovy w
Localizeděščřžýáíí contains [Actually, it does work, though in Java-based
language it's a small miracle]
28 /tmp>
===
?
All the best,
OC
ariable names'
ěěě<<'support accented characters all right'
println "${ěěě.class.simpleName} contains $ěěě"
===
As for variables and argument names, you don't need anything at all for the
latter, nothing but 'def' for the former.
All the best,
OC
On 27.
We have bumped into this parser issue long long ago, see
http://www.groovy-lang.org/mailing-lists.html#nabble-td5722268
All the best,
OC
On 27. 2. 2016, at 23:19, Bay Batu wrote:
> Hello,
>
> I tried it and it looks like an issue about first letter’s case.
>
&
of Expando is just like above, only the init
> is different of course. And of course this is still without the memory
> requirement. Though you could use a map which uses WeakReference for the
> values. Apache Commons ReferenceMap comes here to my mind though.
Hmmm, those weak refs might actually help -- thanks a big lot for pointing that
out! Coming from ObjC background, I tend to forget those (actually today's ObjC
supports the thing, but its comparatively new feature in there).
All the best,
OC
Could you perhaps outline how those two methods x_attach and
x_attached would look like?
Thanks a big lot,
OC
>
> On 12-Feb-2016 4:50 pm, "ocs.cz" wrote:
> Hello there,
>
> have we in Groovy an API which would serve as a reliable replacement of
> “dynamically
30 matches
Mail list logo