nastra commented on a change in pull request #4019: URL: https://github.com/apache/iceberg/pull/4019#discussion_r798294220
########## File path: api/src/main/java/org/apache/iceberg/SnapshotRef.java ########## @@ -0,0 +1,177 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +package org.apache.iceberg; + +import java.io.Serializable; +import java.util.Objects; +import org.apache.iceberg.relocated.com.google.common.base.MoreObjects; +import org.apache.iceberg.relocated.com.google.common.base.Preconditions; + +public class SnapshotRef implements Serializable { Review comment: > I understand, but with that we are then just saving a few lines of code. I don't see much additional benefit, and we break a few code patterns in the codebase including: > > 1. it uses `getSomeValue` instead of `someValue` as method name for getters > 2. we cannot have flexible logic inside the builder to check for specific `ValidationException` and has to do it outside the generated builder > 3. we have separated API module code patterns with some using Immutable and some do not > > that's why I was asking for what are the other benefits. Just for clarification as there seem to be some misinterpretation of how Immutables work (and maybe I did a terrible job in explaining it previously): IMO the biggest benefit is that you get truly immutable objects that are always in a consistent state, thus allowing you to implicitly enforce good engineering practices through those. All the other things (generated builders, JSON support, ...) are additional bonuses that you don't have to use if not needed 1. you can choose any prefix for those methods, so it can be with or without `get` 2. you can still have that flexibility. At the time when I proposed the first PR with Immutables it wasn't clear that this is something that we wanted to have but it doesn't mean that you can't have that with Immutables 3. I'm not sure why it would matter that much if some classes would use Immutables and some wouldn't. As long as you're using the existing API to construct those instances, it shouldn't make a difference for users of those classes. You can have static methods and hide the `ImmutableXyzBuilder` behind it like it's being done in https://github.com/apache/iceberg/blob/063281ab0a7ab72f2927aa19376625f3ff55be97/api/src/main/java/org/apache/iceberg/catalog/Namespace.java#L37-L43. 4. Introducing Immutables doesn't mean that we would have to rewrite everything. We should only do so where it makes sense and where we'd like to make sure things are truly immutable I hope that helps a bit. Anyway, I didn't want to hijack this PR with a discussion around Immutables but rather just propose something that's helpful, so let's move this discussion to a different place :) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
