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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 写道： >>> >>> 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 <[email protected]> >> 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 <[email protected]> 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 >>>>> >>>> >> >>
