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

[Alessio Stalla]

Is the year 2001 "before" the date 2001-06-01? I'd say no, I'd say the year
2001 "contains" any date with year = 2001 so it cannot be logically
"before" or "after" it. Suppose you're sorting people by birth date, and
they can enter either the full date or just the year. How would you
meaningfully compare someone who is born "in 2001" with someone who is born
"in 2001-06-01"? It makes no sense to equate "born in 2001" with "born on
Jan 1st, 2001". I'm using year and day because it's easier to reason about
but it's the same for date and time. A date is an entire day, it's any
point within that day. It's not equal to midnight, at least, not in
general, not in all possible applications. Conflating the two just because
it happens to work for some applications is just bad design imho.

On Thu, 18 Nov 2021 at 17:43, MG  wrote:

> A day, year, etc is evidently never equal to an actual point in time,
> since it is an interval. The question for me is: Can we convert the Date to
> a DateTime so that it has an ordering which is helpful/meaningful in
> practice, without inviting unexpected bugs etc ?
>
> So what concrete scenario do you see where the implicit attaching of
> 00:00:00 to a Date for the sake of comparison:
>
>1.  Leads to a program error in a practical scenario (i.e. not
>constructed and not for applications which control their data types and
>should evidently go DateTime all the way) ?
>2. Leads to an unexpected result, i.e. "does not work for the
>developer or user" ?
>
> You might assume I am dead set on getting this into Groovy, but that is
> not the case. It is just that the counter arguments I have seen to this
> point seemed quite weak to me, so I have taken the position to argue for it
> (wich is the direction I am leaning to) - but convince me otherwise (saying
> "it is just wrong on principal" won't do that, though, unless I buy into
> your principle, which I oftend do not, since for me what is relevant is
> mostly whether it works in practice).
>
> Cheers,
> mg
>
> PS:  The "filling with zeroes" was a fluff comment - that's why it is in
> brackets and has an according smiley at the end ;-)
>
>
>
> On 18/11/2021 16:25, h...@abula.org wrote:
>
> Hi!
>
> Yes, I got that, but step 1 breaks it IMHO.
>
> It' just as wrong as assuming that a year is equivalent to New Year's Day
> that year (at midnight, even).
>
> Filling up with zeroes works when comparing integer numbers with real
> numbers, but that's about it.
>
> For one thing, the integer / real number comparison works both ways. The
> same cannot be said about LocalDateTime and LocalDate.
>
> Sorry...
>
> BR;H2
>
> Den 2021-11-18 16:01, skrev MG:
>
> 1. Implicitly attach Time to Date
> 2. Fill Time with zeroes
> 3. There you go
>
>
> On 18/11/2021 15:45, h...@abula.org wrote:
>
> Re. 5:
>
> But there is nothing to fill up with zeroes...
>
> BR;H2
>
> Den 2021-11-18 15:11, skrev MG:
>
> I don't think that is correct: Time intervals for days, etc always
> need to be chosen so they are overlap free*, i.e. mathematically
> speaking the interval is closed on one end and open on the other, with
> the start of the next interval being the end of the last:
> [t0,t1[ , [t1,t2[ , ...
>
> For finite resolution (i.e. computers; assuming 3 didgits of
> millisecond precision) and the example of 1 day as interval length,
> this would mean that the interval of a day looks like:
> [date 00:00:00.000, date 23:59:59.999]
> or
> [date 00:00:00.000, date+1 00:00:00.000[
>
> To sum up:
>
> 1. I have used the convention to chose the start of the interval to be
>closed, and the end to be open (i.e. t0 is in the interval, whereas
>t1 is not), which I have encountered time and time again, and
>therefore assume to be widely used.
> 2. Using midnight of the following day only makes sense if you invert
>the open-closed end of the interval, which as I said to me is quite
>unusal.
> 3. Using an application dependent time such as 21:00, 23:00, 01:00,
>02:00 or 08:00 (because that is "when the backup runs or has
>finished") is certainly something which no one can expect to be the
>convention in a generally used language, and would imho be a
>terrible idea (apart from the fact that there is no concept on how
>to choose one over the other). It would also violate the sort order
>of Date with DateTime, in the most unexpected way. Applications that
>want/need that will have to use DateTime throughout.
> 4. As I have said, the only other implicit time I would consider
>slightly viable is noon, but as far as least surprise, sort order
>behavior, etc goes, using the start of the day is imho the singular
>choice.
> 5. (Using 00:00:00.000 also follows the time honored IT convention of
>"filling things up with zeroes", if not explicitly told differently
>;-) )
>
> Cheers,
> mg
>
> *Otherwise a point in time could be in more than one interval (e.g.
> belong to more than one day).
>
>
> On 18/11/2021 

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

[Alessio Stalla]

Dates are not something to mess with lightheartedly. All kinds of weird
exceptions exist. In some dates in some timezones, midnight (i.e. 00:00)
does not exist:
https://stackoverflow.com/questions/18489927/a-day-without-midnight
These kinds of implicit conversions may look like they simplify things but
actually they hide nasty bugs under the carpet, that you'll only discover
when it's Jan 1st 2031 and you get angry calls in the morning while you're
hungover, or when your first customer who was born at, I don't know,
1978-08-01 at midnight in the Fiji islands signs up into the application.
Please, don't do that. MySQL did that, and I've already suffered because of
it.

On Thu, 18 Nov 2021 at 14:22, Jochen Theodorou  wrote:

> On 17.11.21 20:28, MG wrote:
> [...]
> >  3. I have never encountered any other assumption than the one that a
> > Date carries the implicit time of midnight (00:00:00.000...). What
> > other time would one logically pick, given that time intervals are
> > by convention typically closed on the left and open on the right ?
>
> But you have here already trouble. you can take the start of the day, or
> the end of the day. both is midnight, both based on the same date, but
> they are basically 24h apart. In my last project we mostly used end of
> the day for example. And in some parts actually 2:00 in the morning,
> because it is the time to run after some processes... which did not
> proof to be a good idea btw.
>
> bye Jochen
>

Re: GDK retrofit for Java functional interfaces

[Alessio Stalla]

ANTLR provides reasonably good error messages most of the time, but
sometimes you have to tweak error handling a bit (in this case, searching
for some more meaningful context to report), and/or refactor the grammar in
a way that causes error reports to be more accurate.

On Thu, 29 Apr 2021 at 17:56, OCsite  wrote:

> 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 finding source problems *extremely* inconvenient :(
>
> All the best,
> OC
>
> Begin forwarded message:
>
> *From: *"o...@ocs.cz" 
> *Subject: **misplaced else inside a closure causes wrong (or at least
> pretty weird) error placement with Parrot*
> *Date: *19 May 2020 at 22:36:06 CEST
> *To: *us...@groovy.apache.org
> *Reply-To: *us...@groovy.apache.org
>
> Hi there,
>
> perhaps this is a known or well-understand issue, but worth reporting IMHO
> (not sure whether worth a ticket; let me please know should I create one
> for this):
>
> ===
> 281 ocs /tmp>  class q {
>  def foo(val) {
>10.times {
>  println "Essentially anything..."
>
>
>
>  println "... can be here, the longer this code, the worse"
>  else println "This is wrong, but see the error report!"
>}
>  }
> }
> 282 ocs /tmp> /usr/local/groovy-2.4.17/bin/groovyc q.groovy
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> q.groovy: 9: unexpected token: else @ line 9, column 7.
> else println "This is wrong, but see the error report!"
> ^
> 1 error
> 283 ocs /tmp> /usr/local/groovy-3.0.3/bin/groovyc q.groovy
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> q.groovy: 3: Unexpected input: '{'; Expecting RBRACE @ line 3, column 14.
>   10.times {
>^
> 1 error
> 284 ocs /tmp>
> ===
>
> All the best,
> OC
>
>
>

Re: More inclusive naming

[Alessio Stalla]

Well, perhaps it ought to be "black" people who get to say whether they
feel offended by white/blacklist, and in that E. Kemokai's answer is very
valuable.
If we're doing this because someone is being hurt by some offending
language, then +1.
If we're doing this to "be on the right side", then -1 for me as this
doesn't solve anyone's problem but our own fear of "being on the wrong
side", and we can be much more effective as a community if we actually do
something concrete against racism and other inequalities (off the top of my
head: give a spotlight to minority Groovy developers on official channels,
create sponsorship programs, etc.).

On Sat, 13 Jun 2020 at 08:41, Balachandran Sivakumar <
balachand...@balachandran.org> wrote:

> Hi,
>
> On 2020-06-13 07:45, MG wrote:
> > Believe me, I do so understand that - but as an atheist by choice from
> > a young age, I do not want to live in a deeply irrational world, where
> > everything you say can be considered racist or insensitive, even if
> > that makes no sense whatsoever, just because somebody believes it to
> > be that way.
>
>   The problem we are trying to solve is "If something could be
> offensive to even a small subset of people, let's try and avoid that as
> much as possible".
>
> And being "sensitive" is about how a person "feels". Rationalism deals
> with "thought" and cannot be used with feelings :) So, this initiative
> is a good one by all of us in an attempt to ensure that even the most
> sensitive person feels "welcome" and included.
>
> > The base of any free and just society for me needs to be reason and
> > concensus, not any part dictating their perceived truth to the other.
>
>   This is a very true statement that we all should keep in mind in
> any community effort. And here, like always, Paul did ask for
> comments/thought :) And I am in favour of the aliases and gradual
> deprecation of names that could be deemed offensive.
>
>
> --
> Thank you,
> Balachandran Sivakumar
>

Re: Modernize groovy?

[Alessio Stalla]

I think that despite what we engineers like to pretend, languages rise and
fall not much because of their features, but because of the platform they
allow you to program.

Groovy used to be bigger because it was pretty much the only dynamic
language to program on the JVM without going too far from Java. And at one
point because of Spring/VMWare. And maybe a bit because of Grails.

Kotlin is bigger today because of JetBrains and Android.

No cool new feature will make people switch from Kotlin to Groovy.

Bottom line: if we wish Groovy to succeed, let's create, maintain, support,
promote, and use tools that can be programmed/extended in Groovy.

On Thu, 30 Apr 2020 at 12:58, mojo2012  wrote:

> Hello guys,
>
> I've been wondering why groovy is kinda losing ground respectively not
> gaining more traction these days. It's a fine language - so why does it not
> kick off like kotlin?
>
> I think these are one of the reasons:
> * The logo looks kinda year "1990 MS Wordart"-style. When I first saw the
> logo I instantly though "Probably this language is not maintained anymore?"
> * Almost all Java devs I've been talking about groovy in the last couple of
> months think that groovy is a purely dynamically-typed language. Which in
> fact turns them off so much, that they don't even want to take a closer
> look.
> * The development experience is subpar comparing to Java (Eclipse, IntelliJ
> and VSCode). Groovy Eclipse is slow, autocompletion is flaky sometimes, etc
>
> These points are just my experience and subjective to some extent.
>
> What can we do to improve the current situation?
>
> # Logo: both the easiest and one of the hardest points at the same time.
> But
> I would like a kotlin/vscode/c# inspired logo :-)
> # Promote @CompileStatic more, emphasise that performance has not to be
> "way
> slower" than java. Integrate a language-level "async"/coroutine support,
> like Dart/C# etc have it.
> # Make IDE-integration a part of the groovy project, maybe by providing an
> official Language Server implementation and IDE integrations (like Dart or
> Haxe do)
>
> What do you guys think?
>
> Cheers,
> Matti
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: Execute a code segment during script compile

[Alessio Stalla]

You wouldn't want to run @Retry({System.exit(0)}) on your server, I presume.

On Mon, 24 Feb 2020 at 00:39, Saravanan Palanichamy 
wrote:

>
>
> On 2020/02/23 23:14:32, Paul King  wrote:
> > Just for future reference, I'd probably start out with such a question on
> > the users mailing list. There are more folks subscribed to that list and
> > writing closures and transforms (using Groovy) are topics which that list
> > covers. If it turned out that Groovy couldn't handle your use case, the
> dev
> > list (developing the language) would be the place to go to ask whether a
> > feature could be added to the language.
> >
> > Having said that, to answer your question, there are quite a lot of
> > things that are possible. Perhaps you could give a concrete simple
> example
> > of the kind of thing you are trying to do. I understand most of what you
> > are saying but a few bits are still a little unclear (to me at least).
> >
> > Cheers, Paul.
> >
> >
> > On Mon, Feb 24, 2020 at 9:06 AM Saravanan Palanichamy <
> chava...@gmail.com>
> > wrote:
> >
> > > Hello
> > >
> > > Is it possible to do this in the groovy AST transformation ->
> > >
> > > a) in a code visitor, visit a closure expression (in the
> > > INSTRUCTION_SELECTION phase)
> > > b) Using the Closure Node, execute this code to determine its results
> > > based on different parameters
> > >
> > > Essentially I want to be able to selectively run a closure defined in
> code
> > > during the compile process. I see you can convert closures into
> strings, is
> > > it possible to compile that string in the middle of a compile process?
> > >
> > > I am not sure this is the right forum for this question, please let me
> > > know if otherwise
> > >
> >
>
> Hello Paul
>
> Thank you for your reply. I am trying to do this specific thing
> a) I allow my developers to write Groovy scripts
> b) I use the script as a DSL to generate actual configuration files needed
> for my service at runtime.
> c) Because I need to translate the code to configuration entries, I need
> to execute some parts of the script to determine config values. For example
>
> @Retry({new RetryParams(10, 20)})
> void runSomeCodeInMyServer() {
> }
>
> In the code above, lets say this code runs on my server, but the server
> needs to be told that the parameters for the thread that executes this is
> to retry it 10 times, with a 20 second interval.
>
> When parsing the groovy script, I need to pull out these 10 and 20 numbers
> from the script. One way to do this is visit the closure, see this was a
> constructor call to RetryParams, and use the numbers there. This seems
> tedious given the number of combinations possible. However if there was way
> for me to run this closure during the AST transform, I can inspect the
> created retryparams object to get my values. Does that make sense?
>
> As I am typing this, I also realize that the closure may call other
> functions which may need to be compiled as well (but I can create compile
> errors there to keep it simple)
>

Re: [ANNOUNCE] Apache Groovy 3.0.0 released

[Alessio Stalla]

Great job folks!
Looking forward to including Groovy 3 in Portofino 6! :)

On Tue, 11 Feb 2020 at 04:37, Andrei Karneyenka / Claz.org 
wrote:

> Congratulations to all us Groovy users :-) This is truly a great moment.
> Thanks to the Groovy team and to contributors for your hard work and
> dedication !
>
> On Mon, Feb 10, 2020 at 8:06 AM Paul King  wrote:
>
>> Dear community,
>>
>> The Apache Groovy team is pleased to announce version 3.0.0 of Apache
>> Groovy.
>> Apache Groovy is a multi-faceted programming language for the JVM.
>> Further details can be found at the https://groovy.apache.org website.
>>
>> We are sure you'll enjoy the features in this new version of Groovy.
>> Your feedback on any unintentional glitches is welcome.
>>
>> This release includes 15 bug fixes/improvements since RC3 as outlined
>> in the changelog:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12345566
>> (There are over 500 new features, improvements and bug fixes since Groovy
>> 2.5!)
>>
>> Sources, convenience binaries, downloadable documentation and an SDK
>> bundle can be found at: https://groovy.apache.org/download.html
>> We recommend you verify your installation using the information on that
>> page.
>>
>> Jars are also available within the major binary repositories.
>>
>> We welcome your help and feedback and in particular want to thank
>> everyone who contributed to this release. We value all forms of
>> contribution from our contributors past and present but special
>> mention for this release should be made to Daniel Sun for his
>> instrumental contributions to the Parrot parser and Eric Milles for
>> his recent improvements to Groovy's static compiler.
>>
>> For more information on how to report problems, and to get involved,
>> visit the project website at https://groovy.apache.org/
>>
>> Best regards,
>>
>> The Apache Groovy team.
>>
>
>
> --
> Andrei Karneyenka,
> Founder, Claz.org
>

Re: [PROPOSAL]About creating open collective for Groovy programming language in the name of Groovy Community

[Alessio Stalla]

For 4. (sponsoring individual developers and encouraging developers to
participate) have you considered BountySource?

On Fri, 11 Jan 2019 at 00:46, MG  wrote:

> Some thoughts from my side:
>
>1. Do we know of any other ASF projects who gathers donations ? Would
>be surprising if we were the first to face these questions...
>2. Also wondering if the following would avoid legal pitfalls: Ask for
>donations for "The Groovy Language", an abstract language concept, which
>has as reference implementation "Apache Groovy" on the JVM platform ?
>3. If Open Collective is bound to a GitHub repo etc, then  going with
>a Patreon o.s. might be the obvious alternative with looser coupling to
>trademarks.
>4. Another idea would be to sponsor individual developers directly. I
>know my son's (American) football team had something like that for their
>European league level players at some point. I know this does not align
>completely with Daniel's intentions of getting more people to actively
>participate, but since it is very similar to a company paying a Groovy
>developer, it would probably avoid all legal pitfalls.
>
> Cheers,
> mg
>
>
> Am 10.01.2019 um 09:20 schrieb Cédric Champeau:
>
> My 2 cents: as a Groovy enthusiast, I like the idea and support it. As a
> Groovy committer and PMC member, however, I have some things to say.
>
> First, it's not very different to have one company paying one developer
> full time to develop Groovy and contribute features than it is to have a
> collective "sponsoring" Groovy. The process of integration is the same: we,
> as PMC members, must make sure neutrality is followed and that no entity is
> coercing Groovy for its own needs. That's why we try to have PMC members
> from different companies. Second, Groovy is a brand name owned by the ASF.
> As such, you should not use "Apache Groovy" without asking for permission
> from legal. It should also be extremely clear that this collective is not
> affiliated with the ASF in any way. The best way for me to do it is that
> effectively no PMC member, and no committer is part of the collective,
> otherwise there's a conflict of interest. Especially, the ASF itself is
> looking for donations, and donations MUST NOT be directed at a specific
> project. There are good reasons for this (in particular, we all benefit
> from the same infrastructure, the same member affiliation, as any other
> project). So it's clear to be that this collective must not be affiliated
> to Groovy. Should you need sponsorship for developing Groovy, feel free to
> do it, but it should never mention that it's an Apache thing. This can make
> it rather complicated with open collective as it requires a GitHub
> repository with stars. I feel you will NOT be allowed to use
> `apache/groovy` for the reasons I described. `groovy/groovy` is an old
> repo, and in any case, the ASF may want to make sure its trademarks are
> respected by preventing you to use this repository.
>
> Said differently: I like the idea, but you need to find a way to do it
> which doesn't involve trademarks or ASF ownership.
>
>
> Le jeu. 10 janv. 2019 à 02:05, Daniel.Sun  a écrit :
>
>> My pleasure :-)
>>
>> Once the open collective created, we will discuss the rules to encourage
>> people to involve the development of Groovy. They have no time on Groovy
>> during work time and may be tired after work, but maybe they want to earn
>> additional money for some reason.
>>
>> Cheers,
>> Daniel.Sun
>>
>>
>>
>>
>> -
>> Apache Groovy committer
>> Blog: http://blog.sunlan.me
>> Twitter: @daniel_sun
>>
>> --
>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>
>
>

Re: [ANNOUNCE] Apache Groovy 2.5.4 released

[Alessio Stalla]

It says 2.5.4 in the title but 2.5.3 in the actual article.

On Mon, 12 Nov 2018 at 13:07, Remko Popma  wrote:

> Blogged: https://blogs.apache.org/groovy/entry/groovy-2-5-4-released
>
> Please share on social media.
>
> On Monday, November 12, 2018, Paul King  wrote:
>
>> Dear community,
>>
>> The Apache Groovy team is pleased to announce version 2.5.4 of Apache
>> Groovy.
>> Apache Groovy is a multi-faceted programming language for the JVM.
>> Further details can be found at the http://groovy.apache.org website.
>>
>> This release is a maintenance release of the GROOVY_2_5_X branch.
>> It is strongly encouraged that all users using prior
>> versions on this branch upgrade to this version.
>>
>> This release includes 15 bug fixes/improvements as outlined in the
>> changelog:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12344270
>>
>> Sources, convenience binaries, downloadable documentation and an SDK
>> bundle can be found at: http://www.groovy-lang.org/download.html
>> We recommend you verify your installation using the information on that
>> page.
>>
>> Jars are also available within the major binary repositories.
>>
>> We welcome your help and feedback and in particular want
>> to thank everyone who contributed to this release.
>>
>> For more information on how to report problems, and to get involved,
>> visit the project website at https://groovy.apache.org/
>>
>> Best regards,
>>
>> The Apache Groovy team.
>>
>

Re: Java 11

[Alessio Stalla]

Oh, thank you. I was fouled by a failing test, but it was my fault.

On Wed, 24 Oct 2018 at 15:41, Daniel.Sun  wrote:

> 2.5.3 supports Java11 and is released.
> 3.0.0 alpha-4 supports Java11 too but not released yet.
>
> P.S. 2.6 is not maintained anymore.
>
>
> Cheers,
> Daniel.Sun
>
>
>
>
> -
> Daniel Sun
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Java 11

[Alessio Stalla]

Hello folks,

is there a timeframe for Java 11 support in Groovy? Right now it barfs on
JDK 11 classes due to ASM not properly supporting them.

Thanks,
Alessio

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Alessio Stalla]

mg,

I'm perfectly ok with s4 in

def s4 = "x=$x"

being a String. What I'm not ok with is to change the semantics of GString
itself to accomodate for this specific case and others, as proposed in the
original mail.
What I suggest is:

   - DO change the type inference of the static compiler for string
   literals.
   - DO change the way literals are interpreted so they produce a String in
   the general case and only produce a GString when assigned to a GString or
   passed as a GString parameter to a method or cast to GString.
   - DON'T change how GString instances work at runtime.


On Thu, 13 Sep 2018 at 21:20, MG  wrote:

> That's why I suggested we might consider introducing an annotation (called
> e.g. @GStringLiteralToString) which allows to switch this behavior,
> together with an explicit syntax (e.g. S"..." / G"...") for forcing a
> string literal to give a String/GString.
>
> The S"..." / G"..." syntax could potentially also be used to unify string
> literal variants and allow to support less often used variants, by adding
> paramters, e.g.:
>
> def groovySourceLine = S(escape:false,interpolate:true,end:'%&!§')"final
> x="\n$xVal" // sets x to "\n" (newline) char + xVal.toString()"%&!§
>
> Cheers,
> mg
>
>
> On 13.09.2018 21:05, MG wrote:
>
> Hi Alessio,
>
> nothing wrong with that, same as for the other, more explicit options:
>
> final String x = 'abc'
>
> String s0 = "x=$x"
> def s1 = (String) "x=$x"
> def s2 = "x=$x" as String
> def s3 = "x=$x".toString()
>
> But I believe Jochen is right in saying that people expect
>
> def s4 = "x=$x"
>
> to give a String, which of course it currently does not:
>
> [s0, s1, s2, s3, s4].eachWithIndex { final o, final int i ->
>   println "$i) ${o.getClass()}: $o"
> }
>
> 0) class java.lang.String: x=abc
> 1) class java.lang.String: x=abc
> 2) class java.lang.String: x=abc
> 3) class java.lang.String: x=abc
> 4) class org.codehaus.groovy.runtime.GStringImpl: x=abc
>
> Cheers,
> mg
>
>
>
> On 13.09.2018 10:11, Alessio Stalla wrote:
>
> Jochen,
>
> what's wrong with
> String s = "this is a GString literal"
> for people who want a String?
> If the problem is type inference, then in
> def s = "this is a GString literal"
> s could be inferred to be a String, while in
> GString s = "this is a GString literal"
> s would be a GString. Similarly for parameters and return values. If you
> want a GString or pass a GString to a method, you get a GString, otherwise
> a String. No need to change the semantics of the GString class itself.
>
>
> On Thu, Sep 13, 2018, 10:01 Jochen Theodorou  wrote:
>
>>
>>
>> Am 12.09.2018 um 13:59 schrieb mg:
>> > But do they expect GString to be immutable, or do they expect a GString
>> > literal to return a String instance (ie for toString() being called
>> > implicitely on it) ?
>>
>> they expect it to be a literal to return String. Us being able to assign
>> a GString to a String does not improve that impression
>>
>>
>> > I would expect the latter. At least I was not aware that the Groovy
>> > "GString concept" is actually based on a GString class when I started
>> > out with Groovy - using def everywhere together with the fact that
>> > Groovy toString|s GString|s when a String is expected do a great job of
>> > obfuscating that.
>>
>> yepp, was actually a goal. GString was supposed to be like a subclass of
>> String. But I never considered that people may not expect subclasses of
>> String.
>>
>> > The question is, where does that lead us... ?
>>
>> I think we need a way similar to GString literals to construct strings.
>> Either something new, or change GString to something else
>>
>> bye Jochen
>>
>
>
>

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Alessio Stalla]

Jochen,

what's wrong with
String s = "this is a GString literal"
for people who want a String?
If the problem is type inference, then in
def s = "this is a GString literal"
s could be inferred to be a String, while in
GString s = "this is a GString literal"
s would be a GString. Similarly for parameters and return values. If you
want a GString or pass a GString to a method, you get a GString, otherwise
a String. No need to change the semantics of the GString class itself.


On Thu, Sep 13, 2018, 10:01 Jochen Theodorou  wrote:

>
>
> Am 12.09.2018 um 13:59 schrieb mg:
> > But do they expect GString to be immutable, or do they expect a GString
> > literal to return a String instance (ie for toString() being called
> > implicitely on it) ?
>
> they expect it to be a literal to return String. Us being able to assign
> a GString to a String does not improve that impression
>
>
> > I would expect the latter. At least I was not aware that the Groovy
> > "GString concept" is actually based on a GString class when I started
> > out with Groovy - using def everywhere together with the fact that
> > Groovy toString|s GString|s when a String is expected do a great job of
> > obfuscating that.
>
> yepp, was actually a goal. GString was supposed to be like a subclass of
> String. But I never considered that people may not expect subclasses of
> String.
>
> > The question is, where does that lead us... ?
>
> I think we need a way similar to GString literals to construct strings.
> Either something new, or change GString to something else
>
> bye Jochen
>

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Alessio Stalla]

But this is not necessarily a problem. It's how mutable objects work.
GString is mutable, transitively. If you want to convert it into an
immutable type, you can already - by calling toString on the GString.

Daniel's example and rationale are about side effects inside the toString
method itself. Which /is/ really poor practice.


On Mon, Sep 10, 2018, 20:33 Jochen Theodorou  wrote:

> On 10.09.2018 18:51, Alessio Stalla wrote:
> > Yes, but a toString method with side effects is a really bad coding
> > practice that won't be fixed simply by reducing the power of GString.
>
> well...
>
> > class Wrapper {
> >   def x
> >   String toString(){x}
> > }
> >
> > def w = new Wrapper(x:1)
> > def gstring = "$w"
> > assert gstring == "1"
> > w.x = 2
> > assert gstring == "2"
> > w = new Wrapper(x:3)
> > assert gstring == "2"
>
> I don't think that example really falls under your really bad coding.
> You have this problem with lists and maps all the time
>
> bye Jochen
>

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Alessio Stalla]

Yes, but a toString method with side effects is a really bad coding
practice that won't be fixed simply by reducing the power of GString. Far
from it. Actually it will manifest in even worse ways. GString merely makes
it visible.
Rather, a compiler warning or IDE warning about side effects in methods
inherited from Object and overriden is a nice, non invasive way of dealing
with the same problem.


On Mon, 10 Sep 2018 at 14:27, Daniel.Sun  wrote:

> What I want to refine is the confusing GString feature shown by the first
> example(toString method with side effects)
>
> P.S.  I never propose to make most of users' code not work and angry.
>
> Cheers,
> Daniel.Sun
>
>
>
>
> -
> Daniel Sun
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0

[Alessio Stalla]

But are users confused by GString today? Or would they be confused if its
behaviour changed and their code stopped working? Also, which users do you
have in mind, noobies, experts, DSL writers, ...?

I for one would like GString to stay the way it is. The examples you
presented don't show problems with GString, rather they show how other
issues can manifest through GString.

The first example is a toString method with side effects, which is
definitely poor practice. If you wanted to showcase in general the
interaction of mutable objects with GString, then the current behavior
(GString reflects the object's state) might actually be what users want.
I.e. GString as a crude but effective template solution.

The second example is a problem with type inference. Accessing a
Map by a key which is not a String should raise a warning. Also
if it's not already the case the static compiler could handle String x =
"$k" by silently inserting a toString() call, i.e., emitting an implicit
type conversion.


On Sun, 9 Sep 2018 at 07:10, Daniel.Sun  wrote:

> Hi MG,
>
>   The original target of the proposal is to make GString not confuse
> users and make GString behave same both in dynamic and static compilation
> mode. so it will only introduces breaking changes just in some edge cases.
>
> Cheers,
> Daniel.Sun
>
>
>
> -
> Daniel Sun
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: a new joint compiler

[Alessio Stalla]

Then it is a bootstrapping issue. You can solve it either using an older
binary version of Groovy to build the new version of Groovy, or writing
enough of a Groovy interpreter in Java that you can build your compiler
with it.

On 23 February 2016 at 12:47, Jochen Theodorou <blackd...@gmx.org> wrote:

>
>
> On 23.02.2016 11:03, Alessio Stalla wrote:
>
>> Why is it hard to add to the build? Is it a bootstrapping issue?
>>
>
> right now we have 2 steps, build the compiler, then use the new compiler
> to build tests and runtime as well as modules. Since I need part of the
> runtime for the compiler in my case, it cannot work like this, unless
> enough of the runtime is Java to run the parts of the new compiler I am
> using. This should be the case, but can be trouble in the future.
>
> bye Jochen
>

Re: a new joint compiler

[Alessio Stalla]

Why is it hard to add to the build? Is it a bootstrapping issue?

On 23 February 2016 at 09:26, Cédric Champeau 
wrote:

> Hi Jochen,
>
> I need more context too. What changes are you talking about? It seems very
> abstract so far. I would be in favor of a joint compiler without stubs in
> Groovy core itself. I think both Gradle and Jetbrains would be interested
> in such a compiler too. And not talking about an incremental compiler.
> What, technically, are the necessary changes?
>
> 2016-02-23 9:18 GMT+01:00 Thibault Kruse :
>
>> I needed some background information, I guess that is given in :
>>
>> http://blackdragsview.blogspot.de/2014/11/a-joint-compiler-for-groovy-and-java.html
>> http://blackdragsview.blogspot.de/2007/07/joint-compilation-in-groovy.html
>>
>> http://wiki.jvmlangsummit.com/images/8/8a/Clement_MixedLanguageProjectCompilationInEclipse.pdf
>>
>> I believe if the joint compiler has good chances of replacing the
>> current compiler it should live in Groovy core. If it is doomed to
>> forever remain an unloved twin, it should be a project of it's own.
>>
>> In the mean time it can either be a separate project with similar
>> package names (for easy migrationinto groovy later) , or an
>> experimental branch of groovy.
>>
>> On Tue, Feb 23, 2016 at 8:37 AM, Jochen Theodorou 
>> wrote:
>> > Hi all,
>> >
>> > During transit I am these days working on a new joint compiler for
>> Groovy,
>> > one that handles Groovy transforms correctly and does not require stubs
>> (we
>> > can still create them).
>> >
>> > The current current version works for several cases and is still
>> incomplete,
>> > but there are some decisions to make in which I would like to ask the
>> people
>> > here about their opinion.
>> >
>> > The main point is actually about keeping the code in Groovy or not and
>> if to
>> > add the code to the Groovy codebase or not.
>> >
>> > A Groovy based joint compiler will not be easy to integrate in our
>> build, if
>> > it is supposed to run with current Groovy. The joint compiler on the
>> other
>> > hand does not require any changes to the current compiler, even though
>> it
>> > could benefit from them. So in theory it would be possible to use any
>> Groovy
>> > 2.x with this joint compiler. I think that could be interesting as well.
>> > Though I have done nothing about build tools so far. At the very least
>> the
>> > best way of integrating them will require some thought - but I am not
>> sure
>> > that just replacing what we currently have in Groovy is the best way
>> here.
>> > And I do like the idea of using Groovy to build Groovy ;)
>> >
>> > Changing the codebase to Java will surely at least double the lines of
>> code
>> > and some logic changes since I do require double dispatch in many
>> places.
>> > But I am still in a proof of concept phase, so there will naturally be
>> many
>> > lines of code more in the future as well.
>> >
>> > And of course, if the integration of such a compiler is not wished for,
>> it
>> > would naturally become its own project.
>> >
>> > So what do other people think about that?
>> >
>> > bye Jochen
>>
>
>