Hi there,
I've tested the thing a bit more, and found it works very nicely, but does not
seem to support generic non-declared named or variable positional arguments at
all.
Do I miss something, or is that simply not possible with @NamedVariant?
What I would need occasionally is something conce
Ah, I though we are discussing the real usage/support, not just the
documentation (which of course can be always improved).
Most probably the proper solution would be change the documentation to
something more-or-less like
===
[def explained without mentioning var] Note that for a seamless comp
in the docs leads you to expect this to be truthy?
>>
>> The very first documented one, namely
>>
>> Class case values match if the switch value is an instance of the class
>>
>> Each class is an instance of java.lang.Class (as actually proves the second
>
Hi there,
is this the intended behaviour?
===
groovy:000> switch (String) { case Class: println "C"; break; case {it
instanceof Class}: println "CC" }
CC
===> null
groovy:000>
===
Based on the switch documented semantic I would presume "C" should be printed
out, not "CC"?
Thanks and all the
Hi there,
the error in the following code is pretty plain, but the way it is being
reported is seriously misleading. Is that the intended behaviour, or a compiler
bug?
===
2074 ocs /tmp> /usr/local/groovy-4.0.18/bin/groovy q
org.codehaus.groovy.control.MultipleCompilationErrorsException: start
Jochen,
> On 15. 1. 2024, at 10:35, Jochen Theodorou wrote:
> If the goal is to give Groovyc a source file and let it compile that,
> but write only certain files... well that is something that could be
> worked out.
Well I don't know.
Theoretically, it would be nice if the compiler wrote only
Hi there,
is this behaviour intentional? Seems to me it should either throw in all these
cases, or in none of them, but as always, I might be missing something of
importance:
===
Groovy Shell (4.0.5, JVM: 1.8.0_181)
Type ':help' or ':h' for help.
a script to
automatically add spaces to all the ?['s which are not on the list.
Still, if Groovy 4.0.5 could fix the problem and parse this same way G3 did, it
would be worlds easier :)
All the best,
OC
> On 9. 9. 2022, at 14:56, o...@ocs.cz wrote:
>
> Daniel,
>
>>
/09/08 13:39:21 Christopher Smith wrote:
>> The parser seems to be interpreting what you mean as a ternary as a
>> null-safe array index.
>>
>> On Thu, Sep 8, 2022, 08:37 o...@ocs.cz wrote:
>>
>>> Hi there,
>>>
>>> I've just de
Email: Use caution with links and attachments.
>
> The parser seems to be interpreting what you mean as a ternary as a null-safe
> array index.
>
> On Thu, Sep 8, 2022, 08:37 o...@ocs.cz <mailto:o...@ocs.cz> <mailto:o...@ocs.cz>> wrote:
> Hi there,
>
> I
Hell. Another G4 problem, which breaks my ASTTs very nicely, is that
CastExpression forbids type change now. Why, on earth? Looks like a commit
57559e53e7219bba114cef07a47d84f72b131875 of 26 Sep 2020, commented as “prevent
typecast expression with null type”
I could well understand something li
Hi there,
I've just decided it's time to upgrade from Groovy 3 to Groovy 4... and
immediately bumped into a problem, which looks like a parser bug in an
extremely trivial scenario, which seems weird.
Do I perhaps miss something? I've checked
https://groovy-lang.org/releasenotes/groovy-4.0.html
Hi there,
are these inconsistencies intentional?
I guess even if not, they would not be worth fixing (if for no other reason,
then to keep backward compatibility with legacy code which happens to rely on
the behaviour), but still, might be worth to point them out, and perhaps warn
the users in
Jan,
as always, I might be missing something of importance, but I believe a Closure
does not have a return type at all (or, more precisely, the return type of all
Closures is, by definition, Object).
After all, is there a way to define a closure which returns a non-object, say,
int? I think no
Hello there,
perhaps it's just me, but I keep bumping into code like
foo.bar.bax!=null?foo.bar.bax:whatever
Note that it cannot be replaced by an Elvis, for it would eat up falses (like
numeric zeroes, empty strings etc.)
In my personal opinion it would be nice to have a null-based Elvis for t
Daniel,
> On 23. 11. 2016, at 12:57 AM, Daniel Sun wrote:
> ?= is similar with *=, +=, etc in their usage, and they are all for
> convenience and readability. So if ?= does not make sense, why others does?
> :-P
Can't speak for Jochen of course, but I daresay the difference is that
> a
Hi there,
> Any thoughts?
Does it support properly "foo[null]", too?
That aside, I would just again like to advocate for an, let's say, „full-safe“
mode, where one could set some switch (probably would need to be a compile-time
one I guess) to get implicitly the „safe mode“ for _all_ exp
Hello there,
is it possible to create an exception which will *not* be caught by a general
handler, only by a specific one? So that e.g., the following code
===
class MySpecialException extends Exception { /* whatever magic needed here */ }
...
def foo() {
throw new MySpecialException()
}
def
Hello there,
does anybody understand how the following code:
===
package cz.ocs.model
class DatabaseContextDelegate extends ERXDatabaseContextDelegate {
NSDictionary databaseContextShouldUpdateCurrentSnapshot(EODatabaseContext
dbCtxt, NSDictionary dic, NSDictionary dic2, EOGlobalID gid, EODa
19 matches
Mail list logo
