You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@drill.apache.org by James Turton <dz...@apache.org> on 2022/01/21 10:25:44 UTC
[DISCUSS] Lombok - friend or foe?
Hi again Devs
This one is simple to describe. Lombok entered the Drill code base this
year, but not everyone feels that Lombok is appropriate for every code
base. To my, fairly limited, understanding the advantage of Lombok is
that boilerplate code is reduced while the disadvantage is the
deployment of code generation magic that can have untoward effects on
build-time tools and IDEs.
So here is a chance to opine on Lombok if you'd like to. My own opinion
is very near neutral and goes something like "It burned me a bit once,
but hasn't since, and less boilerplate is nice. I guess it can stay
<shrug>. I hope I don't regret this one day."
Regards
James
Re: [DISCUSS] Lombok - friend or foe?
Posted by James Turton <dz...@apache.org>.
It's a great suggestion and we must in general keep our eyes open for
suitable tasks for newcomers. I feel there are also reasons for the
making this specific case one we do ourselves, however. If Lombok's
very presence stops newcomers, because they struggle to get going with
their dev tools of choice then, for as as long we have it, they cannot
go directly to working on e.g. a SQL function or a plugin. They must
either make their tools compatible or do our unlomboking for us first.
Entirely separately, Vova volunteered in a Slack message to remove
Lombok based on this email thread. He knows exactly where it's been
applied and what we need from the replacement code in those places, so I
think it would be very quick and error-free for him...
On 2022/01/24 11:24, luoc wrote:
> I recommend creating this small task on GitHub Issues or JIRA, adding the "newcomer" tag to provide a good chance (to contribute) for newcomers.
>
> Supporting new developers is the best thing for the Drill community.
>
> Thanks.
>
>> 2022年1月24日 下午5:01，James Turton <dz...@apache.org> 写道：
>>
>> Okay, let's approach it that way around: remove it entirely, and Lombok can make a return to plugins *after* they start being built and tested away from the main tree, if any plugin authors want it.
>>
>> P.S. Plugins did indeed not annotate any data objects. Lombok's use there, in what I've seen, has been for the automatic generation of stuff like constructors, getters, setters, loggers, toStrings and hashCodes. That's just for interest's sake, not an effort to remotivate Lombok's inclusion.
>>
>> On 2022/01/24 10:16, Paul Rogers wrote:
>>> A quick check of the source suggests that the Easy Format config builder
>>> (which is a nice addition) does not use Lomboc. Someone coded up (or had
>>> their IDE code up) the setters one-by-one. Makes sense, Lombok isn't for
>>> the builder pattern.
>>>
>>> Note that, allowing Lomboc in any part of Drill is the same as allowing it
>>> everywhere. The old CS thing that the only numbers that matter are 0, 1 and
>>> infinity. To do a PR, all tests should pass, which means that the IDE needs
>>> to be able to debug any that have problems. If any plugin uses Lomboc, then
>>> developers have to wrestle with it. (But, what is a plugin doing with data
>>> objects?)
>>>
>>> So, perhaps remove it entirely for now. It can be added back for extensions
>>> when those extensions are separate projects. (Though, adding that
>>> dependency on one extension adds it for everyone. Will there be Lomboc
>>> version conflicts? Should we wait for class loader isolation before
>>> allowing it back?)
>>>
>>> In general, Drill is so large that it should not take on more dependencies
>>> unless they are a huge win. This is a reason to move the obscure plugins
>>> out of the core: mucking with distributed systems should also require one
>>> to muck with Excel.
>>>
>>> - Paul
>>>
>>> On Sun, Jan 23, 2022 at 11:59 PM James Turton <dz...@apache.org> wrote:
>>>
>>>> I'll prepare a PR that unlomboks everything except contrib. Since we're
>>>> talking about contrib splitting off into one or many independent code
>>>> bases (c.f. install "Drill 2 and plug-in organisation"), working to make
>>>> it conform to coding standards that we're selecting for core Drill
>>>> probably won't pay.
>>>>
>>>> On 2022/01/23 01:36, Charles Givre wrote:
>>>>> I guess the question is do we de-lombok what has already been done? I
>>>> really like the builders for plugin configs, but I'm generally in agreement
>>>> that if it is causing problems building, we should ditch it.
>>>>> Best,
>>>>> -- C
>>>>>
>>>>>
>>>>>
>>>>>> On Jan 22, 2022, at 5:02 PM, Ted Dunning <te...@gmail.com> wrote:
>>>>>>
>>>>>> The Lombok story is better in Intellij, possibly because the Lombok devs
>>>>>> use IntelliJ like the majority of devs. Once I knew to install the
>>>> plugin,
>>>>>> things were at least comprehensible.
>>>>>>
>>>>>> But the problem is that it isn't obvious. As a newcomer, you don't know
>>>>>> what you don't know and because Lombok's major effect is code that isn't
>>>>>> there, it isn't obvious where to look.
>>>>>>
>>>>>> The point about it not helping that much due to Drill's design (good
>>>> point,
>>>>>> paul) is apposite, but I think the naive reader issue is even bigger.
>>>>>>
>>>>>> Net, as a person who isn't developing anything for Drill just lately, I
>>>>>> don't think it's a good idea at all.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Jan 22, 2022 at 6:37 AM luoc <lu...@apache.org> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I have a story here. In Oct 2021, I upgraded Eclipse to the latest
>>>> release
>>>>>>> (2021–09) and then found out that the Lombok dependency was added Drill
>>>>>>> repository, So I installed Lombok (as a new plugin) from Eclipse
>>>>>>> Marketplace as I used to. Finally, restarted the IDE and prepared to
>>>> open
>>>>>>> the Drill project, but it is crushed cause by the issue #2956 <
>>>>>>> https://github.com/projectlombok/lombok/issues/2956>, Lombok was not
>>>>>>> available until I looked at a temporary solution..
>>>>>>>
>>>>>>> I use both Eclipse and IDEA, but I use Eclipse more often. I have no
>>>>>>> objection to the use of Lombok, but suggest the following three points
>>>> :
>>>>>>> 1. Could we use Lombok only in `drill-contrib` module?
>>>>>>>
>>>>>>> 2. Could we agree not to use Lombok in common module?
>>>>>>>
>>>>>>> 3. It is best to update the dev documentation to describe this results
>>>> if
>>>>>>> we continue to use Lombok.
>>>>>>>
>>>>>>> In fact, I have the same idea as Paul, more about balancing choices.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>>> 2022年1月22日 下午5:34，Paul Rogers <pa...@gmail.com> 写道：
>>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> I look at any tool as a cost/benefit tradeoff. If Drill were a typical
>>>>>>>> business app, with lots of "data objects", then the hassle of Lomboc
>>>>>>> might
>>>>>>>> be a net win. However, the nature of Drill is that we have very few
>>>> data
>>>>>>>> objects. We have lots of Protobuf objects, or Jackson-serialized
>>>> objects,
>>>>>>>> but not too many data objects of the kind used with object-relational
>>>>>>>> mappers.
>>>>>>>>
>>>>>>>> On the other hand, I had to spend an hour or so trying to figure out
>>>> why
>>>>>>>> things would not build in Eclipse. Then, more time to figure out how
>>>> to
>>>>>>>> install the half-finished Lomboc plugin for Eclipse and various other
>>>>>>>> fiddling.
>>>>>>>>
>>>>>>>> So, I'd guess, on balance, Lombok has cost, and will continue to cost,
>>>>>>> more
>>>>>>>> time than it saved avoiding a few getter/setter methods. And, I agree
>>>>>>> with
>>>>>>>> Ted, Eclipse (and, I assume IntelliJ), is pretty quick at generating
>>>>>>> those
>>>>>>>> methods.
>>>>>>>>
>>>>>>>> Since Lomboc has a cost, and is not a huge win, KISS suggests we avoid
>>>>>>>> adding extra dependencies unnecessarily.
>>>>>>>>
>>>>>>>> That's my 2 cents...
>>>>>>>>
>>>>>>>> - Paul
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Jan 21, 2022 at 8:51 AM Ted Dunning <te...@gmail.com>
>>>>>>> wrote:
>>>>>>>>> A couple of years ago, I had a dev introduce Lombok into some code
>>>>>>> without
>>>>>>>>> me knowing. That let me be a classic naive user.
>>>>>>>>>
>>>>>>>>> The result was total confusion on my part. Sooo much code was being
>>>>>>>>> automagically generated that I couldn't figure out the code and
>>>> spent a
>>>>>>> lot
>>>>>>>>> of time chasing my tail and very little time looking at the crux of
>>>> the
>>>>>>>>> code.
>>>>>>>>>
>>>>>>>>> My own personal preference is either
>>>>>>>>>
>>>>>>>>> - use a language like Julia if you want magic. It's fantastic and
>>>> all to
>>>>>>>>> have amazing stuff and coders expect to see it.
>>>>>>>>>
>>>>>>>>> - use an IDE to generate the boiler plate and put it into its own
>>>> little
>>>>>>>>> annex in the code with the interesting bits near the top of classes.
>>>>>>> That
>>>>>>>>> lets debuggers and IDEs that don't understand Lombok to function
>>>> without
>>>>>>>>> impairing readability much. Concurrent with that, use discipline to
>>>> not
>>>>>>> do
>>>>>>>>> strange things like changing the expected meaning of the boilerplate.
>>>>>>>>>
>>>>>>>>> That's my preference, but I wouldn't want to push that preference
>>>> very
>>>>>>>>> hard. My own prioritization is on readability of the code by
>>>> outsiders.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Jan 21, 2022 at 2:25 AM James Turton <dz...@apache.org>
>>>> wrote:
>>>>>>>>>> Hi again Devs
>>>>>>>>>>
>>>>>>>>>> This one is simple to describe. Lombok entered the Drill code base
>>>>>>> this
>>>>>>>>>> year, but not everyone feels that Lombok is appropriate for every
>>>> code
>>>>>>>>>> base. To my, fairly limited, understanding the advantage of Lombok
>>>> is
>>>>>>>>>> that boilerplate code is reduced while the disadvantage is the
>>>>>>>>>> deployment of code generation magic that can have untoward effects
>>>> on
>>>>>>>>>> build-time tools and IDEs.
>>>>>>>>>>
>>>>>>>>>> So here is a chance to opine on Lombok if you'd like to. My own
>>>>>>> opinion
>>>>>>>>>> is very near neutral and goes something like "It burned me a bit
>>>> once,
>>>>>>>>>> but hasn't since, and less boilerplate is nice. I guess it can stay
>>>>>>>>>> <shrug>. I hope I don't regret this one day."
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> James
>>>>>>>>>>
Re: [DISCUSS] Lombok - friend or foe?
Posted by luoc <lu...@apache.org>.
I recommend creating this small task on GitHub Issues or JIRA, adding the "newcomer" tag to provide a good chance (to contribute) for newcomers.
Supporting new developers is the best thing for the Drill community.
Thanks.
> 2022年1月24日 下午5:01，James Turton <dz...@apache.org> 写道：
>
> Okay, let's approach it that way around: remove it entirely, and Lombok can make a return to plugins *after* they start being built and tested away from the main tree, if any plugin authors want it.
>
> P.S. Plugins did indeed not annotate any data objects. Lombok's use there, in what I've seen, has been for the automatic generation of stuff like constructors, getters, setters, loggers, toStrings and hashCodes. That's just for interest's sake, not an effort to remotivate Lombok's inclusion.
>
> On 2022/01/24 10:16, Paul Rogers wrote:
>> A quick check of the source suggests that the Easy Format config builder
>> (which is a nice addition) does not use Lomboc. Someone coded up (or had
>> their IDE code up) the setters one-by-one. Makes sense, Lombok isn't for
>> the builder pattern.
>>
>> Note that, allowing Lomboc in any part of Drill is the same as allowing it
>> everywhere. The old CS thing that the only numbers that matter are 0, 1 and
>> infinity. To do a PR, all tests should pass, which means that the IDE needs
>> to be able to debug any that have problems. If any plugin uses Lomboc, then
>> developers have to wrestle with it. (But, what is a plugin doing with data
>> objects?)
>>
>> So, perhaps remove it entirely for now. It can be added back for extensions
>> when those extensions are separate projects. (Though, adding that
>> dependency on one extension adds it for everyone. Will there be Lomboc
>> version conflicts? Should we wait for class loader isolation before
>> allowing it back?)
>>
>> In general, Drill is so large that it should not take on more dependencies
>> unless they are a huge win. This is a reason to move the obscure plugins
>> out of the core: mucking with distributed systems should also require one
>> to muck with Excel.
>>
>> - Paul
>>
>> On Sun, Jan 23, 2022 at 11:59 PM James Turton <dz...@apache.org> wrote:
>>
>>> I'll prepare a PR that unlomboks everything except contrib. Since we're
>>> talking about contrib splitting off into one or many independent code
>>> bases (c.f. install "Drill 2 and plug-in organisation"), working to make
>>> it conform to coding standards that we're selecting for core Drill
>>> probably won't pay.
>>>
>>> On 2022/01/23 01:36, Charles Givre wrote:
>>>> I guess the question is do we de-lombok what has already been done? I
>>> really like the builders for plugin configs, but I'm generally in agreement
>>> that if it is causing problems building, we should ditch it.
>>>> Best,
>>>> -- C
>>>>
>>>>
>>>>
>>>>> On Jan 22, 2022, at 5:02 PM, Ted Dunning <te...@gmail.com> wrote:
>>>>>
>>>>> The Lombok story is better in Intellij, possibly because the Lombok devs
>>>>> use IntelliJ like the majority of devs. Once I knew to install the
>>> plugin,
>>>>> things were at least comprehensible.
>>>>>
>>>>> But the problem is that it isn't obvious. As a newcomer, you don't know
>>>>> what you don't know and because Lombok's major effect is code that isn't
>>>>> there, it isn't obvious where to look.
>>>>>
>>>>> The point about it not helping that much due to Drill's design (good
>>> point,
>>>>> paul) is apposite, but I think the naive reader issue is even bigger.
>>>>>
>>>>> Net, as a person who isn't developing anything for Drill just lately, I
>>>>> don't think it's a good idea at all.
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Jan 22, 2022 at 6:37 AM luoc <lu...@apache.org> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I have a story here. In Oct 2021, I upgraded Eclipse to the latest
>>> release
>>>>>> (2021–09) and then found out that the Lombok dependency was added Drill
>>>>>> repository, So I installed Lombok (as a new plugin) from Eclipse
>>>>>> Marketplace as I used to. Finally, restarted the IDE and prepared to
>>> open
>>>>>> the Drill project, but it is crushed cause by the issue #2956 <
>>>>>> https://github.com/projectlombok/lombok/issues/2956>, Lombok was not
>>>>>> available until I looked at a temporary solution..
>>>>>>
>>>>>> I use both Eclipse and IDEA, but I use Eclipse more often. I have no
>>>>>> objection to the use of Lombok, but suggest the following three points
>>> :
>>>>>> 1. Could we use Lombok only in `drill-contrib` module?
>>>>>>
>>>>>> 2. Could we agree not to use Lombok in common module?
>>>>>>
>>>>>> 3. It is best to update the dev documentation to describe this results
>>> if
>>>>>> we continue to use Lombok.
>>>>>>
>>>>>> In fact, I have the same idea as Paul, more about balancing choices.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>>> 2022年1月22日 下午5:34，Paul Rogers <pa...@gmail.com> 写道：
>>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I look at any tool as a cost/benefit tradeoff. If Drill were a typical
>>>>>>> business app, with lots of "data objects", then the hassle of Lomboc
>>>>>> might
>>>>>>> be a net win. However, the nature of Drill is that we have very few
>>> data
>>>>>>> objects. We have lots of Protobuf objects, or Jackson-serialized
>>> objects,
>>>>>>> but not too many data objects of the kind used with object-relational
>>>>>>> mappers.
>>>>>>>
>>>>>>> On the other hand, I had to spend an hour or so trying to figure out
>>> why
>>>>>>> things would not build in Eclipse. Then, more time to figure out how
>>> to
>>>>>>> install the half-finished Lomboc plugin for Eclipse and various other
>>>>>>> fiddling.
>>>>>>>
>>>>>>> So, I'd guess, on balance, Lombok has cost, and will continue to cost,
>>>>>> more
>>>>>>> time than it saved avoiding a few getter/setter methods. And, I agree
>>>>>> with
>>>>>>> Ted, Eclipse (and, I assume IntelliJ), is pretty quick at generating
>>>>>> those
>>>>>>> methods.
>>>>>>>
>>>>>>> Since Lomboc has a cost, and is not a huge win, KISS suggests we avoid
>>>>>>> adding extra dependencies unnecessarily.
>>>>>>>
>>>>>>> That's my 2 cents...
>>>>>>>
>>>>>>> - Paul
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 21, 2022 at 8:51 AM Ted Dunning <te...@gmail.com>
>>>>>> wrote:
>>>>>>>> A couple of years ago, I had a dev introduce Lombok into some code
>>>>>> without
>>>>>>>> me knowing. That let me be a classic naive user.
>>>>>>>>
>>>>>>>> The result was total confusion on my part. Sooo much code was being
>>>>>>>> automagically generated that I couldn't figure out the code and
>>> spent a
>>>>>> lot
>>>>>>>> of time chasing my tail and very little time looking at the crux of
>>> the
>>>>>>>> code.
>>>>>>>>
>>>>>>>> My own personal preference is either
>>>>>>>>
>>>>>>>> - use a language like Julia if you want magic. It's fantastic and
>>> all to
>>>>>>>> have amazing stuff and coders expect to see it.
>>>>>>>>
>>>>>>>> - use an IDE to generate the boiler plate and put it into its own
>>> little
>>>>>>>> annex in the code with the interesting bits near the top of classes.
>>>>>> That
>>>>>>>> lets debuggers and IDEs that don't understand Lombok to function
>>> without
>>>>>>>> impairing readability much. Concurrent with that, use discipline to
>>> not
>>>>>> do
>>>>>>>> strange things like changing the expected meaning of the boilerplate.
>>>>>>>>
>>>>>>>> That's my preference, but I wouldn't want to push that preference
>>> very
>>>>>>>> hard. My own prioritization is on readability of the code by
>>> outsiders.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Jan 21, 2022 at 2:25 AM James Turton <dz...@apache.org>
>>> wrote:
>>>>>>>>> Hi again Devs
>>>>>>>>>
>>>>>>>>> This one is simple to describe. Lombok entered the Drill code base
>>>>>> this
>>>>>>>>> year, but not everyone feels that Lombok is appropriate for every
>>> code
>>>>>>>>> base. To my, fairly limited, understanding the advantage of Lombok
>>> is
>>>>>>>>> that boilerplate code is reduced while the disadvantage is the
>>>>>>>>> deployment of code generation magic that can have untoward effects
>>> on
>>>>>>>>> build-time tools and IDEs.
>>>>>>>>>
>>>>>>>>> So here is a chance to opine on Lombok if you'd like to. My own
>>>>>> opinion
>>>>>>>>> is very near neutral and goes something like "It burned me a bit
>>> once,
>>>>>>>>> but hasn't since, and less boilerplate is nice. I guess it can stay
>>>>>>>>> <shrug>. I hope I don't regret this one day."
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> James
>>>>>>>>>
>>>
Re: [DISCUSS] Lombok - friend or foe?
Posted by James Turton <dz...@apache.org>.
Okay, let's approach it that way around: remove it entirely, and Lombok
can make a return to plugins *after* they start being built and tested
away from the main tree, if any plugin authors want it.
P.S. Plugins did indeed not annotate any data objects. Lombok's use
there, in what I've seen, has been for the automatic generation of stuff
like constructors, getters, setters, loggers, toStrings and hashCodes.
That's just for interest's sake, not an effort to remotivate Lombok's
inclusion.
On 2022/01/24 10:16, Paul Rogers wrote:
> A quick check of the source suggests that the Easy Format config builder
> (which is a nice addition) does not use Lomboc. Someone coded up (or had
> their IDE code up) the setters one-by-one. Makes sense, Lombok isn't for
> the builder pattern.
>
> Note that, allowing Lomboc in any part of Drill is the same as allowing it
> everywhere. The old CS thing that the only numbers that matter are 0, 1 and
> infinity. To do a PR, all tests should pass, which means that the IDE needs
> to be able to debug any that have problems. If any plugin uses Lomboc, then
> developers have to wrestle with it. (But, what is a plugin doing with data
> objects?)
>
> So, perhaps remove it entirely for now. It can be added back for extensions
> when those extensions are separate projects. (Though, adding that
> dependency on one extension adds it for everyone. Will there be Lomboc
> version conflicts? Should we wait for class loader isolation before
> allowing it back?)
>
> In general, Drill is so large that it should not take on more dependencies
> unless they are a huge win. This is a reason to move the obscure plugins
> out of the core: mucking with distributed systems should also require one
> to muck with Excel.
>
> - Paul
>
> On Sun, Jan 23, 2022 at 11:59 PM James Turton <dz...@apache.org> wrote:
>
>> I'll prepare a PR that unlomboks everything except contrib. Since we're
>> talking about contrib splitting off into one or many independent code
>> bases (c.f. install "Drill 2 and plug-in organisation"), working to make
>> it conform to coding standards that we're selecting for core Drill
>> probably won't pay.
>>
>> On 2022/01/23 01:36, Charles Givre wrote:
>>> I guess the question is do we de-lombok what has already been done? I
>> really like the builders for plugin configs, but I'm generally in agreement
>> that if it is causing problems building, we should ditch it.
>>> Best,
>>> -- C
>>>
>>>
>>>
>>>> On Jan 22, 2022, at 5:02 PM, Ted Dunning <te...@gmail.com> wrote:
>>>>
>>>> The Lombok story is better in Intellij, possibly because the Lombok devs
>>>> use IntelliJ like the majority of devs. Once I knew to install the
>> plugin,
>>>> things were at least comprehensible.
>>>>
>>>> But the problem is that it isn't obvious. As a newcomer, you don't know
>>>> what you don't know and because Lombok's major effect is code that isn't
>>>> there, it isn't obvious where to look.
>>>>
>>>> The point about it not helping that much due to Drill's design (good
>> point,
>>>> paul) is apposite, but I think the naive reader issue is even bigger.
>>>>
>>>> Net, as a person who isn't developing anything for Drill just lately, I
>>>> don't think it's a good idea at all.
>>>>
>>>>
>>>>
>>>> On Sat, Jan 22, 2022 at 6:37 AM luoc <lu...@apache.org> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I have a story here. In Oct 2021, I upgraded Eclipse to the latest
>> release
>>>>> (2021–09) and then found out that the Lombok dependency was added Drill
>>>>> repository, So I installed Lombok (as a new plugin) from Eclipse
>>>>> Marketplace as I used to. Finally, restarted the IDE and prepared to
>> open
>>>>> the Drill project, but it is crushed cause by the issue #2956 <
>>>>> https://github.com/projectlombok/lombok/issues/2956>, Lombok was not
>>>>> available until I looked at a temporary solution..
>>>>>
>>>>> I use both Eclipse and IDEA, but I use Eclipse more often. I have no
>>>>> objection to the use of Lombok, but suggest the following three points
>> :
>>>>> 1. Could we use Lombok only in `drill-contrib` module?
>>>>>
>>>>> 2. Could we agree not to use Lombok in common module?
>>>>>
>>>>> 3. It is best to update the dev documentation to describe this results
>> if
>>>>> we continue to use Lombok.
>>>>>
>>>>> In fact, I have the same idea as Paul, more about balancing choices.
>>>>>
>>>>> Thanks.
>>>>>
>>>>>> 2022年1月22日 下午5:34，Paul Rogers <pa...@gmail.com> 写道：
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I look at any tool as a cost/benefit tradeoff. If Drill were a typical
>>>>>> business app, with lots of "data objects", then the hassle of Lomboc
>>>>> might
>>>>>> be a net win. However, the nature of Drill is that we have very few
>> data
>>>>>> objects. We have lots of Protobuf objects, or Jackson-serialized
>> objects,
>>>>>> but not too many data objects of the kind used with object-relational
>>>>>> mappers.
>>>>>>
>>>>>> On the other hand, I had to spend an hour or so trying to figure out
>> why
>>>>>> things would not build in Eclipse. Then, more time to figure out how
>> to
>>>>>> install the half-finished Lomboc plugin for Eclipse and various other
>>>>>> fiddling.
>>>>>>
>>>>>> So, I'd guess, on balance, Lombok has cost, and will continue to cost,
>>>>> more
>>>>>> time than it saved avoiding a few getter/setter methods. And, I agree
>>>>> with
>>>>>> Ted, Eclipse (and, I assume IntelliJ), is pretty quick at generating
>>>>> those
>>>>>> methods.
>>>>>>
>>>>>> Since Lomboc has a cost, and is not a huge win, KISS suggests we avoid
>>>>>> adding extra dependencies unnecessarily.
>>>>>>
>>>>>> That's my 2 cents...
>>>>>>
>>>>>> - Paul
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jan 21, 2022 at 8:51 AM Ted Dunning <te...@gmail.com>
>>>>> wrote:
>>>>>>> A couple of years ago, I had a dev introduce Lombok into some code
>>>>> without
>>>>>>> me knowing. That let me be a classic naive user.
>>>>>>>
>>>>>>> The result was total confusion on my part. Sooo much code was being
>>>>>>> automagically generated that I couldn't figure out the code and
>> spent a
>>>>> lot
>>>>>>> of time chasing my tail and very little time looking at the crux of
>> the
>>>>>>> code.
>>>>>>>
>>>>>>> My own personal preference is either
>>>>>>>
>>>>>>> - use a language like Julia if you want magic. It's fantastic and
>> all to
>>>>>>> have amazing stuff and coders expect to see it.
>>>>>>>
>>>>>>> - use an IDE to generate the boiler plate and put it into its own
>> little
>>>>>>> annex in the code with the interesting bits near the top of classes.
>>>>> That
>>>>>>> lets debuggers and IDEs that don't understand Lombok to function
>> without
>>>>>>> impairing readability much. Concurrent with that, use discipline to
>> not
>>>>> do
>>>>>>> strange things like changing the expected meaning of the boilerplate.
>>>>>>>
>>>>>>> That's my preference, but I wouldn't want to push that preference
>> very
>>>>>>> hard. My own prioritization is on readability of the code by
>> outsiders.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 21, 2022 at 2:25 AM James Turton <dz...@apache.org>
>> wrote:
>>>>>>>> Hi again Devs
>>>>>>>>
>>>>>>>> This one is simple to describe. Lombok entered the Drill code base
>>>>> this
>>>>>>>> year, but not everyone feels that Lombok is appropriate for every
>> code
>>>>>>>> base. To my, fairly limited, understanding the advantage of Lombok
>> is
>>>>>>>> that boilerplate code is reduced while the disadvantage is the
>>>>>>>> deployment of code generation magic that can have untoward effects
>> on
>>>>>>>> build-time tools and IDEs.
>>>>>>>>
>>>>>>>> So here is a chance to opine on Lombok if you'd like to. My own
>>>>> opinion
>>>>>>>> is very near neutral and goes something like "It burned me a bit
>> once,
>>>>>>>> but hasn't since, and less boilerplate is nice. I guess it can stay
>>>>>>>> <shrug>. I hope I don't regret this one day."
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> James
>>>>>>>>
>>
Re: [DISCUSS] Lombok - friend or foe?
Posted by Paul Rogers <pa...@gmail.com>.
A quick check of the source suggests that the Easy Format config builder
(which is a nice addition) does not use Lomboc. Someone coded up (or had
their IDE code up) the setters one-by-one. Makes sense, Lombok isn't for
the builder pattern.
Note that, allowing Lomboc in any part of Drill is the same as allowing it
everywhere. The old CS thing that the only numbers that matter are 0, 1 and
infinity. To do a PR, all tests should pass, which means that the IDE needs
to be able to debug any that have problems. If any plugin uses Lomboc, then
developers have to wrestle with it. (But, what is a plugin doing with data
objects?)
So, perhaps remove it entirely for now. It can be added back for extensions
when those extensions are separate projects. (Though, adding that
dependency on one extension adds it for everyone. Will there be Lomboc
version conflicts? Should we wait for class loader isolation before
allowing it back?)
In general, Drill is so large that it should not take on more dependencies
unless they are a huge win. This is a reason to move the obscure plugins
out of the core: mucking with distributed systems should also require one
to muck with Excel.
- Paul
On Sun, Jan 23, 2022 at 11:59 PM James Turton <dz...@apache.org> wrote:
> I'll prepare a PR that unlomboks everything except contrib. Since we're
> talking about contrib splitting off into one or many independent code
> bases (c.f. install "Drill 2 and plug-in organisation"), working to make
> it conform to coding standards that we're selecting for core Drill
> probably won't pay.
>
> On 2022/01/23 01:36, Charles Givre wrote:
> > I guess the question is do we de-lombok what has already been done? I
> really like the builders for plugin configs, but I'm generally in agreement
> that if it is causing problems building, we should ditch it.
> > Best,
> > -- C
> >
> >
> >
> >> On Jan 22, 2022, at 5:02 PM, Ted Dunning <te...@gmail.com> wrote:
> >>
> >> The Lombok story is better in Intellij, possibly because the Lombok devs
> >> use IntelliJ like the majority of devs. Once I knew to install the
> plugin,
> >> things were at least comprehensible.
> >>
> >> But the problem is that it isn't obvious. As a newcomer, you don't know
> >> what you don't know and because Lombok's major effect is code that isn't
> >> there, it isn't obvious where to look.
> >>
> >> The point about it not helping that much due to Drill's design (good
> point,
> >> paul) is apposite, but I think the naive reader issue is even bigger.
> >>
> >> Net, as a person who isn't developing anything for Drill just lately, I
> >> don't think it's a good idea at all.
> >>
> >>
> >>
> >> On Sat, Jan 22, 2022 at 6:37 AM luoc <lu...@apache.org> wrote:
> >>
> >>> Hi all,
> >>>
> >>> I have a story here. In Oct 2021, I upgraded Eclipse to the latest
> release
> >>> (2021–09) and then found out that the Lombok dependency was added Drill
> >>> repository, So I installed Lombok (as a new plugin) from Eclipse
> >>> Marketplace as I used to. Finally, restarted the IDE and prepared to
> open
> >>> the Drill project, but it is crushed cause by the issue #2956 <
> >>> https://github.com/projectlombok/lombok/issues/2956>, Lombok was not
> >>> available until I looked at a temporary solution..
> >>>
> >>> I use both Eclipse and IDEA, but I use Eclipse more often. I have no
> >>> objection to the use of Lombok, but suggest the following three points
> :
> >>>
> >>> 1. Could we use Lombok only in `drill-contrib` module?
> >>>
> >>> 2. Could we agree not to use Lombok in common module?
> >>>
> >>> 3. It is best to update the dev documentation to describe this results
> if
> >>> we continue to use Lombok.
> >>>
> >>> In fact, I have the same idea as Paul, more about balancing choices.
> >>>
> >>> Thanks.
> >>>
> >>>> 2022年1月22日 下午5:34，Paul Rogers <pa...@gmail.com> 写道：
> >>>>
> >>>> Hi All,
> >>>>
> >>>> I look at any tool as a cost/benefit tradeoff. If Drill were a typical
> >>>> business app, with lots of "data objects", then the hassle of Lomboc
> >>> might
> >>>> be a net win. However, the nature of Drill is that we have very few
> data
> >>>> objects. We have lots of Protobuf objects, or Jackson-serialized
> objects,
> >>>> but not too many data objects of the kind used with object-relational
> >>>> mappers.
> >>>>
> >>>> On the other hand, I had to spend an hour or so trying to figure out
> why
> >>>> things would not build in Eclipse. Then, more time to figure out how
> to
> >>>> install the half-finished Lomboc plugin for Eclipse and various other
> >>>> fiddling.
> >>>>
> >>>> So, I'd guess, on balance, Lombok has cost, and will continue to cost,
> >>> more
> >>>> time than it saved avoiding a few getter/setter methods. And, I agree
> >>> with
> >>>> Ted, Eclipse (and, I assume IntelliJ), is pretty quick at generating
> >>> those
> >>>> methods.
> >>>>
> >>>> Since Lomboc has a cost, and is not a huge win, KISS suggests we avoid
> >>>> adding extra dependencies unnecessarily.
> >>>>
> >>>> That's my 2 cents...
> >>>>
> >>>> - Paul
> >>>>
> >>>>
> >>>>
> >>>> On Fri, Jan 21, 2022 at 8:51 AM Ted Dunning <te...@gmail.com>
> >>> wrote:
> >>>>> A couple of years ago, I had a dev introduce Lombok into some code
> >>> without
> >>>>> me knowing. That let me be a classic naive user.
> >>>>>
> >>>>> The result was total confusion on my part. Sooo much code was being
> >>>>> automagically generated that I couldn't figure out the code and
> spent a
> >>> lot
> >>>>> of time chasing my tail and very little time looking at the crux of
> the
> >>>>> code.
> >>>>>
> >>>>> My own personal preference is either
> >>>>>
> >>>>> - use a language like Julia if you want magic. It's fantastic and
> all to
> >>>>> have amazing stuff and coders expect to see it.
> >>>>>
> >>>>> - use an IDE to generate the boiler plate and put it into its own
> little
> >>>>> annex in the code with the interesting bits near the top of classes.
> >>> That
> >>>>> lets debuggers and IDEs that don't understand Lombok to function
> without
> >>>>> impairing readability much. Concurrent with that, use discipline to
> not
> >>> do
> >>>>> strange things like changing the expected meaning of the boilerplate.
> >>>>>
> >>>>> That's my preference, but I wouldn't want to push that preference
> very
> >>>>> hard. My own prioritization is on readability of the code by
> outsiders.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Fri, Jan 21, 2022 at 2:25 AM James Turton <dz...@apache.org>
> wrote:
> >>>>>
> >>>>>> Hi again Devs
> >>>>>>
> >>>>>> This one is simple to describe. Lombok entered the Drill code base
> >>> this
> >>>>>> year, but not everyone feels that Lombok is appropriate for every
> code
> >>>>>> base. To my, fairly limited, understanding the advantage of Lombok
> is
> >>>>>> that boilerplate code is reduced while the disadvantage is the
> >>>>>> deployment of code generation magic that can have untoward effects
> on
> >>>>>> build-time tools and IDEs.
> >>>>>>
> >>>>>> So here is a chance to opine on Lombok if you'd like to. My own
> >>> opinion
> >>>>>> is very near neutral and goes something like "It burned me a bit
> once,
> >>>>>> but hasn't since, and less boilerplate is nice. I guess it can stay
> >>>>>> <shrug>. I hope I don't regret this one day."
> >>>>>>
> >>>>>> Regards
> >>>>>> James
> >>>>>>
> >>>
>
>
Re: [DISCUSS] Lombok - friend or foe?
Posted by James Turton <dz...@apache.org>.
I'll prepare a PR that unlomboks everything except contrib. Since we're
talking about contrib splitting off into one or many independent code
bases (c.f. install "Drill 2 and plug-in organisation"), working to make
it conform to coding standards that we're selecting for core Drill
probably won't pay.
On 2022/01/23 01:36, Charles Givre wrote:
> I guess the question is do we de-lombok what has already been done? I really like the builders for plugin configs, but I'm generally in agreement that if it is causing problems building, we should ditch it.
> Best,
> -- C
>
>
>
>> On Jan 22, 2022, at 5:02 PM, Ted Dunning <te...@gmail.com> wrote:
>>
>> The Lombok story is better in Intellij, possibly because the Lombok devs
>> use IntelliJ like the majority of devs. Once I knew to install the plugin,
>> things were at least comprehensible.
>>
>> But the problem is that it isn't obvious. As a newcomer, you don't know
>> what you don't know and because Lombok's major effect is code that isn't
>> there, it isn't obvious where to look.
>>
>> The point about it not helping that much due to Drill's design (good point,
>> paul) is apposite, but I think the naive reader issue is even bigger.
>>
>> Net, as a person who isn't developing anything for Drill just lately, I
>> don't think it's a good idea at all.
>>
>>
>>
>> On Sat, Jan 22, 2022 at 6:37 AM luoc <lu...@apache.org> wrote:
>>
>>> Hi all,
>>>
>>> I have a story here. In Oct 2021, I upgraded Eclipse to the latest release
>>> (2021–09) and then found out that the Lombok dependency was added Drill
>>> repository, So I installed Lombok (as a new plugin) from Eclipse
>>> Marketplace as I used to. Finally, restarted the IDE and prepared to open
>>> the Drill project, but it is crushed cause by the issue #2956 <
>>> https://github.com/projectlombok/lombok/issues/2956>, Lombok was not
>>> available until I looked at a temporary solution..
>>>
>>> I use both Eclipse and IDEA, but I use Eclipse more often. I have no
>>> objection to the use of Lombok, but suggest the following three points :
>>>
>>> 1. Could we use Lombok only in `drill-contrib` module?
>>>
>>> 2. Could we agree not to use Lombok in common module?
>>>
>>> 3. It is best to update the dev documentation to describe this results if
>>> we continue to use Lombok.
>>>
>>> In fact, I have the same idea as Paul, more about balancing choices.
>>>
>>> Thanks.
>>>
>>>> 2022年1月22日 下午5:34，Paul Rogers <pa...@gmail.com> 写道：
>>>>
>>>> Hi All,
>>>>
>>>> I look at any tool as a cost/benefit tradeoff. If Drill were a typical
>>>> business app, with lots of "data objects", then the hassle of Lomboc
>>> might
>>>> be a net win. However, the nature of Drill is that we have very few data
>>>> objects. We have lots of Protobuf objects, or Jackson-serialized objects,
>>>> but not too many data objects of the kind used with object-relational
>>>> mappers.
>>>>
>>>> On the other hand, I had to spend an hour or so trying to figure out why
>>>> things would not build in Eclipse. Then, more time to figure out how to
>>>> install the half-finished Lomboc plugin for Eclipse and various other
>>>> fiddling.
>>>>
>>>> So, I'd guess, on balance, Lombok has cost, and will continue to cost,
>>> more
>>>> time than it saved avoiding a few getter/setter methods. And, I agree
>>> with
>>>> Ted, Eclipse (and, I assume IntelliJ), is pretty quick at generating
>>> those
>>>> methods.
>>>>
>>>> Since Lomboc has a cost, and is not a huge win, KISS suggests we avoid
>>>> adding extra dependencies unnecessarily.
>>>>
>>>> That's my 2 cents...
>>>>
>>>> - Paul
>>>>
>>>>
>>>>
>>>> On Fri, Jan 21, 2022 at 8:51 AM Ted Dunning <te...@gmail.com>
>>> wrote:
>>>>> A couple of years ago, I had a dev introduce Lombok into some code
>>> without
>>>>> me knowing. That let me be a classic naive user.
>>>>>
>>>>> The result was total confusion on my part. Sooo much code was being
>>>>> automagically generated that I couldn't figure out the code and spent a
>>> lot
>>>>> of time chasing my tail and very little time looking at the crux of the
>>>>> code.
>>>>>
>>>>> My own personal preference is either
>>>>>
>>>>> - use a language like Julia if you want magic. It's fantastic and all to
>>>>> have amazing stuff and coders expect to see it.
>>>>>
>>>>> - use an IDE to generate the boiler plate and put it into its own little
>>>>> annex in the code with the interesting bits near the top of classes.
>>> That
>>>>> lets debuggers and IDEs that don't understand Lombok to function without
>>>>> impairing readability much. Concurrent with that, use discipline to not
>>> do
>>>>> strange things like changing the expected meaning of the boilerplate.
>>>>>
>>>>> That's my preference, but I wouldn't want to push that preference very
>>>>> hard. My own prioritization is on readability of the code by outsiders.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jan 21, 2022 at 2:25 AM James Turton <dz...@apache.org> wrote:
>>>>>
>>>>>> Hi again Devs
>>>>>>
>>>>>> This one is simple to describe. Lombok entered the Drill code base
>>> this
>>>>>> year, but not everyone feels that Lombok is appropriate for every code
>>>>>> base. To my, fairly limited, understanding the advantage of Lombok is
>>>>>> that boilerplate code is reduced while the disadvantage is the
>>>>>> deployment of code generation magic that can have untoward effects on
>>>>>> build-time tools and IDEs.
>>>>>>
>>>>>> So here is a chance to opine on Lombok if you'd like to. My own
>>> opinion
>>>>>> is very near neutral and goes something like "It burned me a bit once,
>>>>>> but hasn't since, and less boilerplate is nice. I guess it can stay
>>>>>> <shrug>. I hope I don't regret this one day."
>>>>>>
>>>>>> Regards
>>>>>> James
>>>>>>
>>>
Re: [DISCUSS] Lombok - friend or foe?
Posted by Charles Givre <cg...@gmail.com>.
I guess the question is do we de-lombok what has already been done? I really like the builders for plugin configs, but I'm generally in agreement that if it is causing problems building, we should ditch it.
Best,
-- C
> On Jan 22, 2022, at 5:02 PM, Ted Dunning <te...@gmail.com> wrote:
>
> The Lombok story is better in Intellij, possibly because the Lombok devs
> use IntelliJ like the majority of devs. Once I knew to install the plugin,
> things were at least comprehensible.
>
> But the problem is that it isn't obvious. As a newcomer, you don't know
> what you don't know and because Lombok's major effect is code that isn't
> there, it isn't obvious where to look.
>
> The point about it not helping that much due to Drill's design (good point,
> paul) is apposite, but I think the naive reader issue is even bigger.
>
> Net, as a person who isn't developing anything for Drill just lately, I
> don't think it's a good idea at all.
>
>
>
> On Sat, Jan 22, 2022 at 6:37 AM luoc <lu...@apache.org> wrote:
>
>>
>> Hi all,
>>
>> I have a story here. In Oct 2021, I upgraded Eclipse to the latest release
>> (2021–09) and then found out that the Lombok dependency was added Drill
>> repository, So I installed Lombok (as a new plugin) from Eclipse
>> Marketplace as I used to. Finally, restarted the IDE and prepared to open
>> the Drill project, but it is crushed cause by the issue #2956 <
>> https://github.com/projectlombok/lombok/issues/2956>, Lombok was not
>> available until I looked at a temporary solution..
>>
>> I use both Eclipse and IDEA, but I use Eclipse more often. I have no
>> objection to the use of Lombok, but suggest the following three points :
>>
>> 1. Could we use Lombok only in `drill-contrib` module?
>>
>> 2. Could we agree not to use Lombok in common module?
>>
>> 3. It is best to update the dev documentation to describe this results if
>> we continue to use Lombok.
>>
>> In fact, I have the same idea as Paul, more about balancing choices.
>>
>> Thanks.
>>
>>> 2022年1月22日 下午5:34，Paul Rogers <pa...@gmail.com> 写道：
>>>
>>> Hi All,
>>>
>>> I look at any tool as a cost/benefit tradeoff. If Drill were a typical
>>> business app, with lots of "data objects", then the hassle of Lomboc
>> might
>>> be a net win. However, the nature of Drill is that we have very few data
>>> objects. We have lots of Protobuf objects, or Jackson-serialized objects,
>>> but not too many data objects of the kind used with object-relational
>>> mappers.
>>>
>>> On the other hand, I had to spend an hour or so trying to figure out why
>>> things would not build in Eclipse. Then, more time to figure out how to
>>> install the half-finished Lomboc plugin for Eclipse and various other
>>> fiddling.
>>>
>>> So, I'd guess, on balance, Lombok has cost, and will continue to cost,
>> more
>>> time than it saved avoiding a few getter/setter methods. And, I agree
>> with
>>> Ted, Eclipse (and, I assume IntelliJ), is pretty quick at generating
>> those
>>> methods.
>>>
>>> Since Lomboc has a cost, and is not a huge win, KISS suggests we avoid
>>> adding extra dependencies unnecessarily.
>>>
>>> That's my 2 cents...
>>>
>>> - Paul
>>>
>>>
>>>
>>> On Fri, Jan 21, 2022 at 8:51 AM Ted Dunning <te...@gmail.com>
>> wrote:
>>>
>>>> A couple of years ago, I had a dev introduce Lombok into some code
>> without
>>>> me knowing. That let me be a classic naive user.
>>>>
>>>> The result was total confusion on my part. Sooo much code was being
>>>> automagically generated that I couldn't figure out the code and spent a
>> lot
>>>> of time chasing my tail and very little time looking at the crux of the
>>>> code.
>>>>
>>>> My own personal preference is either
>>>>
>>>> - use a language like Julia if you want magic. It's fantastic and all to
>>>> have amazing stuff and coders expect to see it.
>>>>
>>>> - use an IDE to generate the boiler plate and put it into its own little
>>>> annex in the code with the interesting bits near the top of classes.
>> That
>>>> lets debuggers and IDEs that don't understand Lombok to function without
>>>> impairing readability much. Concurrent with that, use discipline to not
>> do
>>>> strange things like changing the expected meaning of the boilerplate.
>>>>
>>>> That's my preference, but I wouldn't want to push that preference very
>>>> hard. My own prioritization is on readability of the code by outsiders.
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Jan 21, 2022 at 2:25 AM James Turton <dz...@apache.org> wrote:
>>>>
>>>>> Hi again Devs
>>>>>
>>>>> This one is simple to describe. Lombok entered the Drill code base
>> this
>>>>> year, but not everyone feels that Lombok is appropriate for every code
>>>>> base. To my, fairly limited, understanding the advantage of Lombok is
>>>>> that boilerplate code is reduced while the disadvantage is the
>>>>> deployment of code generation magic that can have untoward effects on
>>>>> build-time tools and IDEs.
>>>>>
>>>>> So here is a chance to opine on Lombok if you'd like to. My own
>> opinion
>>>>> is very near neutral and goes something like "It burned me a bit once,
>>>>> but hasn't since, and less boilerplate is nice. I guess it can stay
>>>>> <shrug>. I hope I don't regret this one day."
>>>>>
>>>>> Regards
>>>>> James
>>>>>
>>>>
>>
>>
Re: [DISCUSS] Lombok - friend or foe?
Posted by Ted Dunning <te...@gmail.com>.
The Lombok story is better in Intellij, possibly because the Lombok devs
use IntelliJ like the majority of devs. Once I knew to install the plugin,
things were at least comprehensible.
But the problem is that it isn't obvious. As a newcomer, you don't know
what you don't know and because Lombok's major effect is code that isn't
there, it isn't obvious where to look.
The point about it not helping that much due to Drill's design (good point,
paul) is apposite, but I think the naive reader issue is even bigger.
Net, as a person who isn't developing anything for Drill just lately, I
don't think it's a good idea at all.
On Sat, Jan 22, 2022 at 6:37 AM luoc <lu...@apache.org> wrote:
>
> Hi all,
>
> I have a story here. In Oct 2021, I upgraded Eclipse to the latest release
> (2021–09) and then found out that the Lombok dependency was added Drill
> repository, So I installed Lombok (as a new plugin) from Eclipse
> Marketplace as I used to. Finally, restarted the IDE and prepared to open
> the Drill project, but it is crushed cause by the issue #2956 <
> https://github.com/projectlombok/lombok/issues/2956>, Lombok was not
> available until I looked at a temporary solution..
>
> I use both Eclipse and IDEA, but I use Eclipse more often. I have no
> objection to the use of Lombok, but suggest the following three points :
>
> 1. Could we use Lombok only in `drill-contrib` module?
>
> 2. Could we agree not to use Lombok in common module?
>
> 3. It is best to update the dev documentation to describe this results if
> we continue to use Lombok.
>
> In fact, I have the same idea as Paul, more about balancing choices.
>
> Thanks.
>
> > 2022年1月22日 下午5:34，Paul Rogers <pa...@gmail.com> 写道：
> >
> > Hi All,
> >
> > I look at any tool as a cost/benefit tradeoff. If Drill were a typical
> > business app, with lots of "data objects", then the hassle of Lomboc
> might
> > be a net win. However, the nature of Drill is that we have very few data
> > objects. We have lots of Protobuf objects, or Jackson-serialized objects,
> > but not too many data objects of the kind used with object-relational
> > mappers.
> >
> > On the other hand, I had to spend an hour or so trying to figure out why
> > things would not build in Eclipse. Then, more time to figure out how to
> > install the half-finished Lomboc plugin for Eclipse and various other
> > fiddling.
> >
> > So, I'd guess, on balance, Lombok has cost, and will continue to cost,
> more
> > time than it saved avoiding a few getter/setter methods. And, I agree
> with
> > Ted, Eclipse (and, I assume IntelliJ), is pretty quick at generating
> those
> > methods.
> >
> > Since Lomboc has a cost, and is not a huge win, KISS suggests we avoid
> > adding extra dependencies unnecessarily.
> >
> > That's my 2 cents...
> >
> > - Paul
> >
> >
> >
> > On Fri, Jan 21, 2022 at 8:51 AM Ted Dunning <te...@gmail.com>
> wrote:
> >
> >> A couple of years ago, I had a dev introduce Lombok into some code
> without
> >> me knowing. That let me be a classic naive user.
> >>
> >> The result was total confusion on my part. Sooo much code was being
> >> automagically generated that I couldn't figure out the code and spent a
> lot
> >> of time chasing my tail and very little time looking at the crux of the
> >> code.
> >>
> >> My own personal preference is either
> >>
> >> - use a language like Julia if you want magic. It's fantastic and all to
> >> have amazing stuff and coders expect to see it.
> >>
> >> - use an IDE to generate the boiler plate and put it into its own little
> >> annex in the code with the interesting bits near the top of classes.
> That
> >> lets debuggers and IDEs that don't understand Lombok to function without
> >> impairing readability much. Concurrent with that, use discipline to not
> do
> >> strange things like changing the expected meaning of the boilerplate.
> >>
> >> That's my preference, but I wouldn't want to push that preference very
> >> hard. My own prioritization is on readability of the code by outsiders.
> >>
> >>
> >>
> >>
> >> On Fri, Jan 21, 2022 at 2:25 AM James Turton <dz...@apache.org> wrote:
> >>
> >>> Hi again Devs
> >>>
> >>> This one is simple to describe. Lombok entered the Drill code base
> this
> >>> year, but not everyone feels that Lombok is appropriate for every code
> >>> base. To my, fairly limited, understanding the advantage of Lombok is
> >>> that boilerplate code is reduced while the disadvantage is the
> >>> deployment of code generation magic that can have untoward effects on
> >>> build-time tools and IDEs.
> >>>
> >>> So here is a chance to opine on Lombok if you'd like to. My own
> opinion
> >>> is very near neutral and goes something like "It burned me a bit once,
> >>> but hasn't since, and less boilerplate is nice. I guess it can stay
> >>> <shrug>. I hope I don't regret this one day."
> >>>
> >>> Regards
> >>> James
> >>>
> >>
>
>
Re: [DISCUSS] Lombok - friend or foe?
Posted by luoc <lu...@apache.org>.
Hi all,
I have a story here. In Oct 2021, I upgraded Eclipse to the latest release (2021–09) and then found out that the Lombok dependency was added Drill repository, So I installed Lombok (as a new plugin) from Eclipse Marketplace as I used to. Finally, restarted the IDE and prepared to open the Drill project, but it is crushed cause by the issue #2956 <https://github.com/projectlombok/lombok/issues/2956>, Lombok was not available until I looked at a temporary solution..
I use both Eclipse and IDEA, but I use Eclipse more often. I have no objection to the use of Lombok, but suggest the following three points :
1. Could we use Lombok only in `drill-contrib` module?
2. Could we agree not to use Lombok in common module?
3. It is best to update the dev documentation to describe this results if we continue to use Lombok.
In fact, I have the same idea as Paul, more about balancing choices.
Thanks.
> 2022年1月22日 下午5:34，Paul Rogers <pa...@gmail.com> 写道：
>
> Hi All,
>
> I look at any tool as a cost/benefit tradeoff. If Drill were a typical
> business app, with lots of "data objects", then the hassle of Lomboc might
> be a net win. However, the nature of Drill is that we have very few data
> objects. We have lots of Protobuf objects, or Jackson-serialized objects,
> but not too many data objects of the kind used with object-relational
> mappers.
>
> On the other hand, I had to spend an hour or so trying to figure out why
> things would not build in Eclipse. Then, more time to figure out how to
> install the half-finished Lomboc plugin for Eclipse and various other
> fiddling.
>
> So, I'd guess, on balance, Lombok has cost, and will continue to cost, more
> time than it saved avoiding a few getter/setter methods. And, I agree with
> Ted, Eclipse (and, I assume IntelliJ), is pretty quick at generating those
> methods.
>
> Since Lomboc has a cost, and is not a huge win, KISS suggests we avoid
> adding extra dependencies unnecessarily.
>
> That's my 2 cents...
>
> - Paul
>
>
>
> On Fri, Jan 21, 2022 at 8:51 AM Ted Dunning <te...@gmail.com> wrote:
>
>> A couple of years ago, I had a dev introduce Lombok into some code without
>> me knowing. That let me be a classic naive user.
>>
>> The result was total confusion on my part. Sooo much code was being
>> automagically generated that I couldn't figure out the code and spent a lot
>> of time chasing my tail and very little time looking at the crux of the
>> code.
>>
>> My own personal preference is either
>>
>> - use a language like Julia if you want magic. It's fantastic and all to
>> have amazing stuff and coders expect to see it.
>>
>> - use an IDE to generate the boiler plate and put it into its own little
>> annex in the code with the interesting bits near the top of classes. That
>> lets debuggers and IDEs that don't understand Lombok to function without
>> impairing readability much. Concurrent with that, use discipline to not do
>> strange things like changing the expected meaning of the boilerplate.
>>
>> That's my preference, but I wouldn't want to push that preference very
>> hard. My own prioritization is on readability of the code by outsiders.
>>
>>
>>
>>
>> On Fri, Jan 21, 2022 at 2:25 AM James Turton <dz...@apache.org> wrote:
>>
>>> Hi again Devs
>>>
>>> This one is simple to describe. Lombok entered the Drill code base this
>>> year, but not everyone feels that Lombok is appropriate for every code
>>> base. To my, fairly limited, understanding the advantage of Lombok is
>>> that boilerplate code is reduced while the disadvantage is the
>>> deployment of code generation magic that can have untoward effects on
>>> build-time tools and IDEs.
>>>
>>> So here is a chance to opine on Lombok if you'd like to. My own opinion
>>> is very near neutral and goes something like "It burned me a bit once,
>>> but hasn't since, and less boilerplate is nice. I guess it can stay
>>> <shrug>. I hope I don't regret this one day."
>>>
>>> Regards
>>> James
>>>
>>
Re: [DISCUSS] Lombok - friend or foe?
Posted by Paul Rogers <pa...@gmail.com>.
Hi All,
I look at any tool as a cost/benefit tradeoff. If Drill were a typical
business app, with lots of "data objects", then the hassle of Lomboc might
be a net win. However, the nature of Drill is that we have very few data
objects. We have lots of Protobuf objects, or Jackson-serialized objects,
but not too many data objects of the kind used with object-relational
mappers.
On the other hand, I had to spend an hour or so trying to figure out why
things would not build in Eclipse. Then, more time to figure out how to
install the half-finished Lomboc plugin for Eclipse and various other
fiddling.
So, I'd guess, on balance, Lombok has cost, and will continue to cost, more
time than it saved avoiding a few getter/setter methods. And, I agree with
Ted, Eclipse (and, I assume IntelliJ), is pretty quick at generating those
methods.
Since Lomboc has a cost, and is not a huge win, KISS suggests we avoid
adding extra dependencies unnecessarily.
That's my 2 cents...
- Paul
On Fri, Jan 21, 2022 at 8:51 AM Ted Dunning <te...@gmail.com> wrote:
> A couple of years ago, I had a dev introduce Lombok into some code without
> me knowing. That let me be a classic naive user.
>
> The result was total confusion on my part. Sooo much code was being
> automagically generated that I couldn't figure out the code and spent a lot
> of time chasing my tail and very little time looking at the crux of the
> code.
>
> My own personal preference is either
>
> - use a language like Julia if you want magic. It's fantastic and all to
> have amazing stuff and coders expect to see it.
>
> - use an IDE to generate the boiler plate and put it into its own little
> annex in the code with the interesting bits near the top of classes. That
> lets debuggers and IDEs that don't understand Lombok to function without
> impairing readability much. Concurrent with that, use discipline to not do
> strange things like changing the expected meaning of the boilerplate.
>
> That's my preference, but I wouldn't want to push that preference very
> hard. My own prioritization is on readability of the code by outsiders.
>
>
>
>
> On Fri, Jan 21, 2022 at 2:25 AM James Turton <dz...@apache.org> wrote:
>
> > Hi again Devs
> >
> > This one is simple to describe. Lombok entered the Drill code base this
> > year, but not everyone feels that Lombok is appropriate for every code
> > base. To my, fairly limited, understanding the advantage of Lombok is
> > that boilerplate code is reduced while the disadvantage is the
> > deployment of code generation magic that can have untoward effects on
> > build-time tools and IDEs.
> >
> > So here is a chance to opine on Lombok if you'd like to. My own opinion
> > is very near neutral and goes something like "It burned me a bit once,
> > but hasn't since, and less boilerplate is nice. I guess it can stay
> > <shrug>. I hope I don't regret this one day."
> >
> > Regards
> > James
> >
>
Re: [DISCUSS] Lombok - friend or foe?
Posted by Ted Dunning <te...@gmail.com>.
A couple of years ago, I had a dev introduce Lombok into some code without
me knowing. That let me be a classic naive user.
The result was total confusion on my part. Sooo much code was being
automagically generated that I couldn't figure out the code and spent a lot
of time chasing my tail and very little time looking at the crux of the
code.
My own personal preference is either
- use a language like Julia if you want magic. It's fantastic and all to
have amazing stuff and coders expect to see it.
- use an IDE to generate the boiler plate and put it into its own little
annex in the code with the interesting bits near the top of classes. That
lets debuggers and IDEs that don't understand Lombok to function without
impairing readability much. Concurrent with that, use discipline to not do
strange things like changing the expected meaning of the boilerplate.
That's my preference, but I wouldn't want to push that preference very
hard. My own prioritization is on readability of the code by outsiders.
On Fri, Jan 21, 2022 at 2:25 AM James Turton <dz...@apache.org> wrote:
> Hi again Devs
>
> This one is simple to describe. Lombok entered the Drill code base this
> year, but not everyone feels that Lombok is appropriate for every code
> base. To my, fairly limited, understanding the advantage of Lombok is
> that boilerplate code is reduced while the disadvantage is the
> deployment of code generation magic that can have untoward effects on
> build-time tools and IDEs.
>
> So here is a chance to opine on Lombok if you'd like to. My own opinion
> is very near neutral and goes something like "It burned me a bit once,
> but hasn't since, and less boilerplate is nice. I guess it can stay
> <shrug>. I hope I don't regret this one day."
>
> Regards
> James
>