Is 'val' too magic?
Reinier Zwitserloot
about this too: "val" is unique because source containing it contains
no link whatsoever to something lombok related. All the other features
are annotation powered, and the annotation is a real thing, in a
lombok package, where javadoc (or, failing that, a search for "lombok
java" or "lombok.Getter", etcetera) will let someone who has no idea
what's happening figure it out.
No such luck for val.
But I think I know of a way to fix that. We could make this class:
package lombok;
/** javadoc descriving what this does goes here */
public final class val {}
and require that you import it prior to using val. We wouldn't do the
val replacement trick until you do, and thus as you program and write
val, all you'd have to do is use your IDE's usual features for
importing something you just wrote (i.e. cmd+shift+I or O or whatever
it is in eclipse, I redefined my key bindings, or cmd+1 to pick
'import xyz' from the quickfix menu). Once lombok notices the import,
_or_ you write "lombok.val" instead of "val", we know that's what you
meant, and we know, as its a real class now, folks without lombok will
be able to find it. Running 'jump to declaration' on a NON-lombokized
eclipse will even get you to val. On a lombokized eclipse, that'll
take you to the type val becomes.
The disadvantage is that you have to add "import lombok.val;" to your
source. A small price to pay, you probably import loads of things.
How about it?
Jacek Furmankiewicz
--
You received this message because you are subscribed to the Google
Groups group for http://projectlombok.org/
To post to this group, send email to project...@googlegroups.com
To unsubscribe from this group, send email to
project-lombo...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/project-lombok?hl=en
Reinier Zwitserloot
Depending on what Roel thinks we might go for it anyway, but an
annotation is just too much effort. You'd have to use a dummy type
which is just confusing. You can't write:
@Val x = whatever;
you'd have to write:
@Val Object x = whatever;
The first one is not legal because annotations are not legal on
assignments, only on declarations, and those MUST have a type to parse
as such. Too much boilerplate. Heh.
On Nov 23, 6:27 pm, Jacek Furmankiewicz <jace...@gmail.com> wrote:
> Personally, I still don't like it.
>
> I would have preferred a @Val annotation on a regular Java variable or
> something like that that accomplishes the same thing.
> I think adding new Java keywords and essentially forking Java should be
> avoided as a general rule.
>
> But I seem to be in a minority here. :-)
>
> > To post to this group, send email to project...@googlegroups.com
> > To unsubscribe from this group, send email to
Fabrizio Giudici
>
> The disadvantage is that you have to add "import lombok.val;" to your
> source. A small price to pay, you probably import loads of things.
>
> How about it?
To me it makes sense. As you said, val is a one-of-its-kind feature and
with the import trick it would sound a bit more coherent with the
general approach of lombok...
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio...@tidalwave.it
Hamlet D'Arcy
to use the Predicate API. The rest of the library still works great.
We all agreed on the best usage and then simply don't use the stuff we
don't want to. I am sure the same approach would work in practice for
lombok. Don't like val? Don't use it.
--
Hamlet D'Arcy
haml...@gmail.com
> --
> You received this message because you are subscribed to the Google
> Groups group for http://projectlombok.org/
>
> To post to this group, send email to project...@googlegroups.com
> To unsubscribe from this group, send email to
> project-lombo...@googlegroups.com
Julien Viet
Jacek Furmankiewicz
Maaartin-1
> But I think I know of a way to fix that. We could make this class:
>
> package lombok;
>
> /** javadoc descriving what this does goes here */
> public final class val {}
/** javadoc */
<T> public T with(T) {
throw new RuntimeException("You should...");
}
could be a member of this (or another) class. Actually, the return type
is not T (since the "proxy" method have different return type), but it
comes closed to (and doesn't matter much).
> The disadvantage is that you have to add "import lombok.val;" to your
> source. A small price to pay, you probably import loads of things.
Nice for the people not knowing lombok. With more such features, I'd be
happy if I'd need to do a single thing to allow all of them. Something
like annotating the whole class with @Lombok(10) could do, and the
version number would even allow you to do some incompatible changes when
necessary.
I'd be even happier if I could declare it once on the line specifying
the java agent, since the readability for people not knowing lombok
doesn't concern me.
There's still the problem of forking Java, but probably there's only one
thing you could do about it: Make it so useful and so well-known
that it makes it's way to JDK.
However, I don't see the big difference between extending Java using
annotations or using context-sensitive keywords. Whatever you do, it
either doesn't compile or it doesn't run or it does the wrong thing.
About the same holds for using any library, except for the dependency on
lombok being only compile-time.
The only bad thing would be to provide a feature incompatible with a
better feature planned for Java, or doing something in a way precluding
or complicating further improvements. I don't think it could be the case
with "val".
Haakon Nilsen
package lombok;
/** javadoc descriving what this does goes here */
public final class val {}
Reinier Zwitserloot
On Nov 23, 9:03 pm, Haakon Nilsen <haak...@gmail.com> wrote:
Marius Kruger
...
> But I think I know of a way to fix that. We could make this class:
>
> package lombok;
>
> /** javadoc descriving what this does goes here */
> public final class val {}
> The disadvantage is that you have to add "import lombok.val;" to your
> source. A small price to pay, you probably import loads of things.
>
> How about it?
+1
import lombok.val; is the best way to future-proof this IMHO;
then we'd be safe if oracle/jcp/java/whatever eventually wakes up and
adds a val keyword.
--
my 2c
<>< Marius ><>