osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [LANG] Adding isEmpty and isNotEmpty methods to ObjectUtils


I must admit to playing a bit of devil's advocate here ;-) with my laundry
list of sizeable kind of objects but I am sure you get my point: As soon as
we add a method like this, the we will get requests for adding more to it
release after release. I'm not against it, but it make you wonder about
adding a Sizeable interface ;-)

Gary

On Fri, Aug 17, 2018 at 10:33 AM Alexander Tsvetkov <
alexander.tsvetkov.93@xxxxxxxxx> wrote:

> Hi Gary,
>
> Yes, you can make the argument that the user might expect *every* class
> with a length(), size() or isEmpty() method to be covered by the
> implementation, but IMO as long as the Javadoc clearly states what is
> supported and what is not, then it's better to have at least a partial
> implementation that covers the more common use-cases than nothing at all.
> I'll be happy to hear what others think about this though.
>
> Regarding your examples:
> - StringBuffer and StringBuilder are already covered by the current
> implementation, since they both implement CharSequence.
> - Buffer - Not sure about this one. Input from others is appreciated here.
> - File, Path, Clob, Lob, AtomicReference, ZipFile - I doubt that these can
> be considered common use-cases, but I may be a bit affected by what we need
> this method for. We have an implementation in our code base that is used
> for:
>   1) Ignoring empty fields when serializing objects to YAML and JSON
> without checking their type.
>   2) Resolving values of placeholders in a generic way. The types of the
> objects is still limited to strings, lists and maps, however.
> Other people may use similar methods for other things, but from what I've
> seen (in our projects and in Spring), most people use such methods to check
> "simple" objects like the ones covered in the current implementation.
>
> Best regards,
> Alexander
>
>
> 2018-08-17 19:01 GMT+03:00 Gary Gregory <garydgregory@xxxxxxxxx>:
>
> > If we open that Pandora's box, then I want to add:
> >
> > - File, empty if length is 0
> > - Path, empty if name length is 0
> > - Buffer, what?
> > - StringBuffer
> > - StringBuilder
> > - java.sql.Clob
> > - java.sql.Lob
> > - The content of an AtomicReference
> > - ZipFile
> > - on and on for anything that has a "size()" or "length" or "length()"
> >
> > ?
> >
> > Gary
> >
> >
> > On Fri, Aug 17, 2018 at 2:43 AM Alexander Tsvetkov <
> > alexander.tsvetkov.93@xxxxxxxxx> wrote:
> >
> > > Hi all,
> > >
> > > First of all, apologies if I have messed something up - this is my
> first
> > > attempt at contributing to Apache.
> > >
> > > With that said, I'd like to propose adding two new methods to Commons
> > > Lang's ObjectUtils class:
> > >   - isEmpty()
> > >   - isNotEmpty()
> > >
> > > These would check whether the object is empty (or not empty
> respectively)
> > > based on its type:
> > >   - CharSequence - Considered empty if its length is zero.
> > >   - Array - Considered empty if its length is zero.
> > >   - Collection - Considered empty if it has zero elements.
> > >   - Map - Considered empty if it has zero key-value mappings.
> > > The object would be considered "not-empty" if its type is not one of
> the
> > > types mentioned above.
> > >
> > > There is an already existing method that does exactly this in Spring's
> > > ObjectUtils (see
> > >
> > > https://github.com/spring-projects/spring-framework/blob/
> > 2ac23badee02697c5eb87c46f955387b32a0d581/spring-core/src/
> > main/java/org/springframework/util/ObjectUtils.java#L134
> > > ),
> > > but I think it would be helpful to people (myself and my team included)
> > if
> > > there was a similar method in Commons Lang's ObjectUtils. That way we
> > > wouldn't have to add a dependency to Spring or re-implement the method
> in
> > > our code base.
> > >
> > > What do you think?
> > >
> > > I've opened a JIRA ticket and a GitHub pull request as well:
> > > https://issues.apache.org/jira/browse/LANG-1411
> > > https://github.com/apache/commons-lang/pull/342
> > >
> > > Best regards,
> > > Alexander
> > >
> >
>