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
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
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
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
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
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
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
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
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
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
/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
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,
>
>>
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.
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,
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
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
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
>
MG,
> On 6. 2. 2025, at 21:05, MG wrote:
> I was talking about an ideal world, as a starting point on how things imho
> should behave (and why), as the point towards which one should try to move as
> far as constraints such as backward compatibility allows.
In ideal world there should be compi
Well but again, making List throw in future would break a vast codebase, which
is a big no-no.
Far as I know, there's no auto-extending unless you explicitly ask for that by
withDefault.
Thanks and all the best,
OC
> On 6. 2. 2025, at 20:16, MG wrote:
>
> My take on this for list-like struct
ne is
forced to uglies like “(arr as List).withDefault...”. That's one thing I would
add; could hardly break any current code I'd say? Or do I overlook something of
importance?
> On 6. 2. 2025, at 20:37, o...@ocs.cz wrote:
>
> Well but again, making List throw in future wou
Mauro,
> On 6. 2. 2025, at 18:24, Mauro Molinari wrote:
> Isn't the contract of List requiring to throw an IndexOutOfBoundsException
> though, in case index is invalid?
Far as the API contract goes, I guess it would be probably an undocumented
behaviour (which actually makes sense, allowing ea
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
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
P.S. Sorry I see I forgot to add the test for the seconds case (caller side
Map, no such thing at the receiver):
===
1054 ocs /tmp> /usr/local/groovy-4.0.25/bin/groovy q
a:[a:1] b:Hi c:there
1056 ocs /tmp>
===
> On 11. 4. 2025, at 16:12, o...@ocs.cz wrote:
>
> Christopher,
Christopher,
> On 11. 4. 2025, at 15:55, Christopher Smith wrote:
> I personally find it surprising and confusing that arguments are implicitly
> collected in method calls; I recently was baffled until I realized that the
> Map as a first argument was causing Groovy to group the leading argumen
> def foo(Map a, b, c) {
> // ...
> }
>
> foo(a:'a', 'b', 'c', x: 'also a')
> From: o...@ocs.cz
> Sent: Friday, April 11, 2025 9:16 AM
> To: Groovy_Developers
> Subject: [EXT] Re: Lists in annotations
>
> External Email:
26 matches
Mail list logo
