Hey all,
I'm very grateful for your feedback, and it's clear that you aren't
convinced that this will be helpful enough to be an Apache-sponsored
project. With that in mind, I ask this:
If you don't think it's good enough, then do something about it. Mentor me.
1. GSoC participant organizations are under no obligation to use the code
at the end of the project, and not a single cent comes out of the
organization's pocket for the work.
2. All that would be required of any mentor is a brief survey of my
progress every 4 weeks and giving me access to people who can answer
questions over the course of the summer.
3. If it *truly* ends up not being useful, then all you've done is 1: allow
a moderately-niche tool to be developed, and 2: provide a young creator
with the skills to be a POWERFUL Groovy contributor in the future. But, if
it ends up being what I think it is, then you've both allowed a
tremendously-helpful project to succeed and created the best advertisement
for Groovy possible. Either way, everyone involved wins.
This idea is provably workable, I believe it fills a niche that is not
currently covered by Groovy, and I have the connections to popularize its
usage. If you don't trust anything, trust that.
Please consider mentoring for this project. Even if it flops, it will be a
tremendous experience that can only help my contributions to Apache in the
future.
Thank you,
Caleb Brandt
On Wed, Mar 27, 2024 at 8:28 AM Jochen Theodorou <blackd...@gmx.org> wrote:
> On 25.03.24 21:17, Caleb Brandt wrote:
> [...]
>
> If you do
>
> class X {
> String foo = "bar"
> get() { return this.foo; }
> set(x) { this.foo = x; doSomethingElse()}
> }
>
> then the call to doSomethingElse is on line 4. But what will happen if
> the IDE find doSomethingElse does not exist and wants to mark the call?
> If the IDE works on the Java code for this the position will be wrong.
> Yes, you would get an error message that is fitting as in
> "soSomethingElse not found"... maybe even the correct line. This means
> your IDE would have to know how to translate back to the code you
> actually wrote. That is why this probably ends up as extension for the
> compiler... which the IDEs may or may not support. I think Manifold is
> doing that.
>
> > We all know what a getter and a setter is, so condensing them into one
> > place is easy to understand.
>
> Sure, then I can write
> private String foo = ("bar", {->this.foo}, {x->this.foo=;
> doSomethingElse()})
> And you will totally understand... right.. right?? I mean there are so
> much in one place, you can barely compress this more and still write the
> code. Well.. to get more serious again. You should not underestimate the
> challenges of language design. And yes, this can be as bad as: "eh... it
> is using begin/end instead of curly braces? Nah, don't like it".. "why
> are there no blocks? There are? Oh the space is significant for this!?".
> And I am not kidding. the first Is a C-guy disliking anything Pascal,
> the second is all about Python.
>
> > But what's a "closure"? What's a
> > "delegate"? What's a "virtual thread"??? (I'm kidding.) People don't
> > have a basis for these things in Java, so it's just /more/ stuff to
> > learn instead of already making sense to a Java-only programmer.
>
> closures are quite similar to lambdas. The delegate concept is not the
> difficult part. The difficult part is that you attach a code block to a
> method and then the method does something with the code block. Ah yes...
> conceptually those lambdas are also very near to anonymous inner
> classes. A concept existing in Java for a long time already. It is all
> about the approach really. Of course if the people you are showing this
> are not open to the concepts and different views, then you can forget
> about it. I for example never discuss with people about static
> compilation if I get the impression they are thinking the false security
> of static compilation solves all their problems in life.
>
> [...]
> > Every addition needs to scan like Java at face value and
> > feel like something Oracle themselves would have added.
>
> With lambdas they did quite the style break in my opinion. They did it
> before though... with enums for example. And don't get me started about
> generics or the switch-case. I really doubt I would be able to tell of a
> new feature if it is as if Oracle themselves would have added it. In the
> end that is not the key-point. It is how the new features work and look
> together with the overall language. For example we had a feature request
> to support "statement if expression", meaning "if (expression)
> statement". Which exists in some language, but we decided against,
> because it does not fit the style of the Groovy language.
>
> [...]
> > _*1. WE CAN USE JAVA'S TOOLS*
> > _
> > Yeah so remember what I said about how "nothing will ever match Java in
> > a Java space"? If you can't beat 'em, join 'em. By acting as a
> > transparent frontend to real Java source code, we can leverage existing
> > Java analyzers to do our linting for us.
>
> But it is not fully transparent. It is one-way.
>
> > The IntelliJ system already
> > has a variant of this for CLion's macro processing, being able to detect
> > errors in the applied macro and display the code it'll be replaced with
> > in a hover popup.
>
> But the preprocessor in C/C++ was made part of the compiler even though
> it originally existed and was intended as independent tool. It just did
> not work, because of the line numbering being messed up. Back in the day
> there existed quite a few languages that transpiled to C, all of them
> got eventually their own compiler. In the word of gcc for example you
> have many languages that compile to shared representation in memory,
> which is then actually compiled to the target platform. This way you
> have a front-end for Modula and one for C++, but lots of the back-end
> part is still the same. In the end it is still like transpiling to C,
> just on a different level, where the source does not matter.
>
> > We can also use Java debuggers to their fullest extent too: it'll link
> > to the processed Java8 sources when we freeze on a breakpoint instead of
> > the J+ sources, but once again that's a /feature/, not a bug. With a
> > good enough formatter on the processor, they'll even thank us for it.
>
> For this there is actually support in the Java bytecode world. If the
> IDE can figure out from the file name attribute and the class name what
> file to open, then the correct position in that source can be opened.
> In your case the opened source would have to be the generated Java
> source, since the IDE would not automatically know how that position
> translates to a position in J+ sources.
>
> [...]
> > No Java syntax rules are broken either - nothing new goes outside a
> > method, for starters - so any community-made Java source plugins will
> > work exactly the same on the unprocessed source as they would on the
> > vanilla source.
>
> I think your getter/setter sugar has potential to break this.
>
> > String foo = "bar";
> >
> > get() {
> > return foo;
> > }
> >
> > set(newVal) {
> > foo = newVal;
> > doOtherThing();
> > }
>
> If I let Javadoc process this, it will not see getBar and setBar, it
> will see get() and set(newVal), probably getting a fit other the
> variable not having a type. And if you have multiple properties you will
> have multiple set and get method with very equal signatures. Many tools
> will not expect that, since that is not valid Java syntax.
>
> [...]
> > People won't have any excuse /not/ to use it.
>
> People have excuses for still using Java8. I myself hated generics so
> much I tried to avoid using them for many years whenever possible. And I
> still try to use them sparingly.
>
> bye blackdrag
>
>
>
