Re: [EXT] seems like a bug to me?

https://issues.apache.org/jira/browse/GROOVY-11565 > On 3. 2. 2025, at 16:01, Milles, Eric (TR Technology) via dev > wrote: > > 1209 ocs /tmp> if (foo) ; > else ; > 1210 ocs /tmp> /usr/local/groovy-4.0.25/bin/groovy q > Caught: BUG! exception in phase 'conversion' in source unit > '/private/t

Re: null-specific argument type?

Hi there! Just a followup (of a message posted to the users maillist, quoted below). Meantime I've found that in the case with a single argument, as shown originally, I can use typeless (well, Object) argument and the method is selected all right, as it is with foo. What seems quite weird thou

Re: @NamedVariant vs @VisibilityOptions

AST transforms running into a Groovy feature. > Groovy doesn't let you compile this class: > > class Foo { >private foo() {} >public foo(String s) {} > } > > It might seem strange but it has been that way for a long time. > > Can you change "makeSense&

@NamedVariant vs @VisibilityOptions

Hi there, do I make some mistake not understanding properly those two ASTTs, or is this a Groovy bug? Thanks! OC === 975 ocs /tmp> /usr/local/groovy-4.0.24/bin/groovy nv org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: /private/tmp/nv.groovy: 4: Mixing private an

Re: [EXT] Using `var` as method return type placeholder

Gianluca, > On 10. 12. 2024, at 9:20, Gianluca Sartori wrote: > ... The use of "var", as of today, falls "only" into the "beauty" category > because there is no real need for it. I might be wrong and I might have misunderstood something of importance, but it seems to me there is one (and only

Re: [EXT] for loops, returns, and other animals

d to Groovy or not, regardless the particular implementation (perhaps I should not have added the exception-based example at all). Thanks and all the best, OC > > From: OCsite > Sent: Wednesday, December 4, 2024 11:03 AM > To: dev@groovy.apache.org > Subject: [EXT] for loops, r

for loops, returns, and other animals

MG, > On 4. 12. 2024, at 16:11, MG wrote: > e.g. using a for(foo : foos) { ... } loop instead of canonical Groovy > foos.each { foo -> ... }, to be able to easily return from the for body from > multiple places using return statements. For one, I would argue that the native and groovier (since

Override new (was: [EXT] Using `var` as method return type placeholder)

Hi there, > On 23. 11. 2024, at 4:12, MG wrote: > Groovy new can be overridden to return a different type on purpose can it? How? (Aside of an ASTT which would be a bit at the complex side for such a trivial thing.) I must have missed this thing in the documentation somewhere, and searching th

possible parser problem?

Hi there, is this my fault, for I missed some documentation somewhere, or a parser fault, for it should have recognised the bool as the 1st and string as the 2nd argument and just call “test” with “true, 'oops'” in the last case (as I've, perhaps mistakenly, assumed)? === 782 ocs /tmp> prin

Re: switch does not recognise Class?

m_source=link&utm_campaign=sig-email&utm_content=webmail> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > On Mon, Jul 1, 2024 at 6:52 AM OCsite wrote: >> >> Christopher, >> >> On 30. 6. 2024, at 22:42, Christopher Smith wrote: >> >> Yo

Re: switch does not recognise Class?

Christopher, > On 30. 6. 2024, at 22:42, Christopher Smith wrote: > You're comparing `class java.lang.String` and `class java.lang.Class`. > No, I'm not. > Which rule in the docs leads you to expect this to be truthy? > The very first documented one, namely Class case values match if the switc

Re: weird error report

Jochen, > On 15. 5. 2024, at 14:18, Jochen Theodorou wrote: > On 13.05.24 16:16, o...@ocs.cz wrote: > [...] >> 2074 ocs /tmp> > def all=['hi','there'].findAll { it.startsWith('h')) } >> 2075 ocs /tmp> /usr/local/groovy-4.0.18/bin/groovy q >> org.codehaus.groovy.control.MultipleCompilationErrorsEx

Re: [EXT] weird error report

Miles, > On 13. 5. 2024, at 17:43, Milles, Eric (TR Technology) via dev > wrote: > When the parser cannot work out the meaning, it tends to report "unexpected > input". I don't complain at all that the error is reported as an “unexpected input”; I do apologise I haven't explained it in detail

Re: [GSoC 2024] Idea: A Basic Superset of Java | Java+

Caleb, > On 24. 3. 2024, at 16:57, Caleb Brandt wrote: >> I know you made Groovy, but if you're anything like me, you love Java. just for one, although I haven't co-operated on the Groovy creation (am just a very satisfied user), I hate Java very bitterly. The language design is simply terribl

Re: Closure Class Files Recreation

Guys, sorry for brevity, in a hurry now. If you are considering a real support, note please that the name-based detection of generated classes won't work without parsing the source due to the darned packages: unless you parse the source, you can't know in which target sub-folder the generated

Re: Closure Class Files Recreation

MG, I might be wrong (haven't checked for a long long time and at least a couple of major Groovy versions), but I believe groovyc always simply re-creates all the .class files which result from a source compiled (could be a number of them: aside of the closure classes, groovyc — very reasonably

wrong work with property names in newer 4's

Hi there, after upgrading to 4.11, our code stopped working. Eventually I've succeeded to isolate the problem — looks like it is not able to properly distinguish a property foo and a method isFoo anymore: === 147 ocs /tmp> /usr/local/groovy-4.0.0-alpha-1/bin/groovy q OP false OP false OP false

Re: StackTrace sanitization list

Hi there, not sure if it helps, but myself, I've played with the sanitizer, and eventually wrote my own track dumper which does two parts: - first, it dumps my own code only (plus some extras, e.g., for internally compiled scripts it shows the offending line, etc.) - after that, it dumps full st

Re: [EXT] A feature request: comparing LocalDate and LocalDateTime using built-in operators.

Guys, I might have missed something of importance somewhere for I haven't read the full thread, so please ignore me if I am repeating something already throughly debated. Nevertheless, based on the part I did read, it sort of looks like you perhaps might possibly have missed that any value wit

Re: Record enhancements

e discovered via Intellisense are two reasons I could think > of that speak for the toList()/toMap() approach... > > Cheers, > mg > > On 02/11/2021 12:48, OCsite wrote: >> Hi there, >> >> I am probably missing something obvious here, but why adding separate

Re: Record enhancements

Hi there, I am probably missing something obvious here, but why adding separate methods for this instead of simply reusing asType? Thanks and all the best, OC > On 2. 11. 2021, at 8:35, Paul King wrote: > > Thanks for the feedback! I added "toMap()" to the PR. > > On Tue, Nov 2, 2021 at 7:02

Re: Groovy 4 and the new integrated query module

MG, > On 27 Sep 2021, at 20:36, MG wrote: > I assume with slur you probably mean "chink" > (https://en.wikipedia.org/wiki/Chink )? I wondered too, myself :) Searching, aside of the above, I've also found that the perfectly nice and drinkable word “gin” might

Re: java.lang.NullPointerException: Pretty Printed Helpful NPEs ?

Hi there, if the NPE management is being worked on, I'd like to again advocate for a way to switch on a “default-safe” mode, be it a compiler switch, an annotation, whatever. With this mode on, the compiler would use the “safe“ (more precisely, null-propagation) mode by default all the time wi

Re: GDK retrofit for Java functional interfaces

Christopher, > On 29 Apr 2021, at 16:57, Christopher Smith wrote: > Parrot has reduced my frustration levels about 15% across the board did it indeed? Weird. In my case, the very opposite is true; compare please e.g. the problem outlined below (which applies in 3.0.8 just as well) — it makes f

Re: Local variable declaration enhancements -- statement scoping

with a number at > the end for short term / loop / etc variables, and for parameters and > variables who live throughout a method or larger block I use no number > postfix or longer names; the short name / long name meta at least is quite > common, I think) > > Cheers, &g

Re: Local variable declaration enhancements -- statement scoping

Hello there, when touching this stuff, it would be extremely desirable primarily to fix the scoping/obscuring of same-named variables, which Groovy at the moment does wrong, same as the demented Java thing: === 89 ocs /tmp> /usr/local/groovy-4.0.0-alpha-1/bin/groovy q org.codehaus.groovy.contr

Re: code of conduct

+1 to what Konstantin wrote, and also my two Zimbabwe cents' worth: myself, I actually think it's harmful — albeit very slightly —, for things like this actually teach people not to behave unless they are explicitly told to. Of course, this is an infinitesimally small incentive not to “behave r

Re: [PROPOSAL]Support conditional return

Daniel, -1. In my personal experience this happens very rarely, not worth a special support in the language by far. Almost all similar cases for me are covered by simple def foo() { ... ... bar()?:defaultValue } and the cases where this is not adequate, either due a non-null false return

Re: "super" object expression for attribute, property, and method call

ath. > VariableScopeVisitor handles matching variable expressions to members. > StaticTypeCheckingVisitor and AsmCLassGenerator perform additional checking > and resolution. > > From: OCsite mailto:o...@ocs.cz>> > Sent: Saturday, June 27, 2020 6:21 AM > To: dev@gr

Re: "super" object expression for attribute, property, and method call

support splitting an implementation of one big class in more sources, like Objective C categories do. (Lately traits came pretty close, but they still are not quite there.) > In any case I think the annotation approach is mostly superior. Absolutely, +1 on that. All the best, OC > > On

Re: "super" object expression for attribute, property, and method call

gt; I thought "super" was more clear, but I am quite concerned that any change > > in the property handling could be a breaking change for someone's code base. > > > > -Original Message- > > From: Jochen Theodorou mailto:blackd...@gmx.org>>

Re: "super" object expression for attribute, property, and method call

a predetermined file extension for its source files"... > > Cheers, > mg > > > On 26/06/2020 18:14, Jochen Theodorou wrote: >> On 26.06.20 18:02, OCsite wrote: >>> >>>> On 26 Jun 2020, at 17:46, Daniil Ovchinnikov >>>> >>&g

Re: "super" object expression for attribute, property, and method call

Jochen, > On 26 Jun 2020, at 18:14, Jochen Theodorou wrote: > > On 26.06.20 18:02, OCsite wrote: >> >>> On 26 Jun 2020, at 17:46, Daniil Ovchinnikov >>> >> <mailto:daniil.ovchinni...@jetbrains.com>> wrote: >>>> when located within

Re: "super" object expression for attribute, property, and method call

Jochen, [...] > the point was about migrating Java code to Groovy though - the reason > why we have many constructs in Groovy we do not really need. > > [...] >> What if there's a case when someone /would/ want a limited recursion? >> >> def getX() { some_condition?this.x:1 } >> >> That said, a

Re: "super" object expression for attribute, property, and method call

. I >> thought "super" was more clear, but I am quite concerned that any change in >> the property handling could be a breaking change for someone's code base. >> >> -Original Message- >> From: Jochen Theodorou >> Sent: Friday, Jun

Re: "super" object expression for attribute, property, and method call

ng change for someone's code base. > > -Original Message- > From: Jochen Theodorou > Sent: Friday, June 26, 2020 10:21 AM > To: dev@groovy.apache.org > Subject: Re: "super" object expression for attribute, property, and method > call > > On

Re: "super" object expression for attribute, property, and method call

Jochen, > On 26 Jun 2020, at 17:33, Jochen wrote: > > On 26.06.20 17:21, Jochen Theodorou wrote: > [...] >> public class X { >> private String foo; >> public String getFoo(){ return this.foo; } >> public void setFoo(String foo){ this.foo = foo; } >> } >> >> This works perfectly fine in Ja

Re: "super" object expression for attribute, property, and method call

ect field access > seems intuitive to me; OC raises some concern. When "x" is a member of the > current class and a subclass, things start to get complicated. > > class A { > def x = 1 > def m() { x } > } > class B extends A { > def x = 2 > def ge

Re: "super" object expression for attribute, property, and method call

Hi there, note please that IMO, this.foo definitely should go through the getFoo getter if there's one; that is does not happen currently I regard as a pretty grave bug, for it breaks encapsulation. Compare please e.g. http://groovy.329449.n5.nabble.com/Inconsistency-properties-are-accessed-as-

Re: More inclusive naming

Ladies — if any in this sad debate — and gentlemen, > Well, perhaps it ought to be "black" people who get to say whether they feel > offended by white/blacklist Indeed. Myself, I invariably find thoughts of Walter E. Williams highly worth studying. Amongst others, he also wrote “The true test

Re: logo permission

> , though certainly much less widely known... > > On 21/05/2020 03:59, OCsite wrote: >> Indeed! >> >> https://commons.wikimedia.org/wiki/File:California_Lone_Star_Flag_1836.svg >> <https://commons.wikimedia.org/wiki/File:California_Lone_Star_Flag_1836.svg> &g

Re: logo permission

Indeed! https://commons.wikimedia.org/wiki/File:California_Lone_Star_Flag_1836.svg :) > On 21 May 2020, at 3:54, Jim White wrote: > > On Wed, May 20, 2020 at 6:49 PM MG > wrote: > NEVER ?