You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Claude Warren <cl...@xenei.com> on 2016/10/08 23:45:44 UTC
putting types in the diamond....
I know that in Java 8 the old
{code}
Map<String> m = new HashMap<String>();
{code}
can now be written as
{code}
Map<String> m = new HashMap<>();
{code}
But why? I suppose in the above it is simple to figure out what is being
constructed however if the declaration of the var and the constructor are
separated is it not confusing? Do we have a standard/guideline for this in
the Jena code?
Suppose:
{code}
MyClass<String> myClass = null;
// .... some lines later
myClass = new MyClass<>();
{code}
makes it difficult to quickly determine the type that myClass is using.
Perhaps I am just tilting at windmills, or am an old curmudgeon.
Guidance please,
Claude
.
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: putting types in the diamond....
Posted by "A. Soroka" <aj...@virginia.edu>.
Okay, I have PR #176 out now (which is I think what gave an immediate reason to Claude to raise this question) with much use of the diamond operator in it. I'll review it for alignment with these points. That PR isn't going to merge until after 3.1.1 is released, so there is time.
---
A. Soroka
The University of Virginia Library
> On Oct 9, 2016, at 5:19 AM, Claude Warren <cl...@xenei.com> wrote:
>
> That sounds exactly like what I was thinking! I wanted to see what others
> thought and find out if there was a good reason to go one way or the other.
>
> Claude
>
> On Sun, Oct 9, 2016 at 1:10 AM, A. Soroka <aj...@virginia.edu> wrote:
>
>> (It was actually Java 7 that introduced the "diamond operator".)
>>
>> I don't know that we have a guideline. I personally like to have policy in
>> hand for questions like these, but I'm not sure we can in this case. Let me
>> give another example, taken directly from the codebase:
>>
>> private final Map<GraphListener, Stack<SecuredGraphListener>> listenerMap
>> = new HashMap<GraphListener, Stack<SecuredGraphListener>>();
>>
>> That seems to me to read much better as:
>>
>> private final Map<GraphListener, Stack<SecuredGraphListener>> listenerMap
>> = new HashMap<>();
>>
>> because the repetition of the type parameters doesn't add any real
>> information for the reader. But you are right to point to other examples
>> wherein the repetition is really helpful. Here are some rules of thumb (not
>> rules to constrain the code, just helpful hints) that I would be ready to
>> uphold:
>>
>> If you are constructing an object to fill a reference as you declare it,
>> use <>. Repeating the type parameters doesn't help anyone understand what
>> is going on, and it can be very verbose.
>>
>> Otherwise, consider how far away the declaration in question lives. If
>> that is far enough, consider repeating the type parameters to obviate the
>> need for readers to go back and forth in the code base.
>>
>> Does that sound reasonable?
>>
>> ---
>> A. Soroka
>> The University of Virginia Library
>>
>>> On Oct 8, 2016, at 7:45 PM, Claude Warren <cl...@xenei.com> wrote:
>>>
>>> I know that in Java 8 the old
>>> {code}
>>> Map<String> m = new HashMap<String>();
>>> {code}
>>> can now be written as
>>> {code}
>>> Map<String> m = new HashMap<>();
>>> {code}
>>> But why? I suppose in the above it is simple to figure out what is being
>>> constructed however if the declaration of the var and the constructor are
>>> separated is it not confusing? Do we have a standard/guideline for this
>> in
>>> the Jena code?
>>>
>>> Suppose:
>>> {code}
>>> MyClass<String> myClass = null;
>>>
>>> // .... some lines later
>>>
>>> myClass = new MyClass<>();
>>> {code}
>>>
>>> makes it difficult to quickly determine the type that myClass is using.
>>> Perhaps I am just tilting at windmills, or am an old curmudgeon.
>>>
>>> Guidance please,
>>> Claude
>>>
>>> .
>>>
>>>
>>> --
>>> I like: Like Like - The likeliest place on the web
>>> <http://like-like.xenei.com>
>>> LinkedIn: http://www.linkedin.com/in/claudewarren
>>
>>
>
>
> --
> I like: Like Like - The likeliest place on the web
> <http://like-like.xenei.com>
> LinkedIn: http://www.linkedin.com/in/claudewarren
Re: putting types in the diamond....
Posted by Claude Warren <cl...@xenei.com>.
That sounds exactly like what I was thinking! I wanted to see what others
thought and find out if there was a good reason to go one way or the other.
Claude
On Sun, Oct 9, 2016 at 1:10 AM, A. Soroka <aj...@virginia.edu> wrote:
> (It was actually Java 7 that introduced the "diamond operator".)
>
> I don't know that we have a guideline. I personally like to have policy in
> hand for questions like these, but I'm not sure we can in this case. Let me
> give another example, taken directly from the codebase:
>
> private final Map<GraphListener, Stack<SecuredGraphListener>> listenerMap
> = new HashMap<GraphListener, Stack<SecuredGraphListener>>();
>
> That seems to me to read much better as:
>
> private final Map<GraphListener, Stack<SecuredGraphListener>> listenerMap
> = new HashMap<>();
>
> because the repetition of the type parameters doesn't add any real
> information for the reader. But you are right to point to other examples
> wherein the repetition is really helpful. Here are some rules of thumb (not
> rules to constrain the code, just helpful hints) that I would be ready to
> uphold:
>
> If you are constructing an object to fill a reference as you declare it,
> use <>. Repeating the type parameters doesn't help anyone understand what
> is going on, and it can be very verbose.
>
> Otherwise, consider how far away the declaration in question lives. If
> that is far enough, consider repeating the type parameters to obviate the
> need for readers to go back and forth in the code base.
>
> Does that sound reasonable?
>
> ---
> A. Soroka
> The University of Virginia Library
>
> > On Oct 8, 2016, at 7:45 PM, Claude Warren <cl...@xenei.com> wrote:
> >
> > I know that in Java 8 the old
> > {code}
> > Map<String> m = new HashMap<String>();
> > {code}
> > can now be written as
> > {code}
> > Map<String> m = new HashMap<>();
> > {code}
> > But why? I suppose in the above it is simple to figure out what is being
> > constructed however if the declaration of the var and the constructor are
> > separated is it not confusing? Do we have a standard/guideline for this
> in
> > the Jena code?
> >
> > Suppose:
> > {code}
> > MyClass<String> myClass = null;
> >
> > // .... some lines later
> >
> > myClass = new MyClass<>();
> > {code}
> >
> > makes it difficult to quickly determine the type that myClass is using.
> > Perhaps I am just tilting at windmills, or am an old curmudgeon.
> >
> > Guidance please,
> > Claude
> >
> > .
> >
> >
> > --
> > I like: Like Like - The likeliest place on the web
> > <http://like-like.xenei.com>
> > LinkedIn: http://www.linkedin.com/in/claudewarren
>
>
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: putting types in the diamond....
Posted by "Bruno P. Kinoshita" <ki...@apache.org>.
Sounds good to me
+1
>________________________________
> From: A. Soroka <aj...@virginia.edu>
>To: dev@jena.apache.org
>Sent: Sunday, 9 October 2016 1:10 PM
>Subject: Re: putting types in the diamond....
>
>
>(It was actually Java 7 that introduced the "diamond operator".)
>
>I don't know that we have a guideline. I personally like to have policy in hand for questions like these, but I'm not sure we can in this case. Let me give another example, taken directly from the codebase:
>
>private final Map<GraphListener, Stack<SecuredGraphListener>> listenerMap = new HashMap<GraphListener, Stack<SecuredGraphListener>>();
>
>That seems to me to read much better as:
>
>private final Map<GraphListener, Stack<SecuredGraphListener>> listenerMap = new HashMap<>();
>
>because the repetition of the type parameters doesn't add any real information for the reader. But you are right to point to other examples wherein the repetition is really helpful. Here are some rules of thumb (not rules to constrain the code, just helpful hints) that I would be ready to uphold:
>
>If you are constructing an object to fill a reference as you declare it, use <>. Repeating the type parameters doesn't help anyone understand what is going on, and it can be very verbose.
>
>Otherwise, consider how far away the declaration in question lives. If that is far enough, consider repeating the type parameters to obviate the need for readers to go back and forth in the code base.
>
>Does that sound reasonable?
>
>---
>A. Soroka
>The University of Virginia Library
>
>
>> On Oct 8, 2016, at 7:45 PM, Claude Warren <cl...@xenei.com> wrote:
>>
>> I know that in Java 8 the old
>> {code}
>> Map<String> m = new HashMap<String>();
>> {code}
>> can now be written as
>> {code}
>> Map<String> m = new HashMap<>();
>> {code}
>> But why? I suppose in the above it is simple to figure out what is being
>> constructed however if the declaration of the var and the constructor are
>> separated is it not confusing? Do we have a standard/guideline for this in
>> the Jena code?
>>
>> Suppose:
>> {code}
>> MyClass<String> myClass = null;
>>
>> // .... some lines later
>>
>> myClass = new MyClass<>();
>> {code}
>>
>> makes it difficult to quickly determine the type that myClass is using.
>> Perhaps I am just tilting at windmills, or am an old curmudgeon.
>>
>> Guidance please,
>> Claude
>>
>> .
>>
>>
>> --
>> I like: Like Like - The likeliest place on the web
>> <http://like-like.xenei.com>
>> LinkedIn: http://www.linkedin.com/in/claudewarren
>
>
>
Re: putting types in the diamond....
Posted by "A. Soroka" <aj...@virginia.edu>.
(It was actually Java 7 that introduced the "diamond operator".)
I don't know that we have a guideline. I personally like to have policy in hand for questions like these, but I'm not sure we can in this case. Let me give another example, taken directly from the codebase:
private final Map<GraphListener, Stack<SecuredGraphListener>> listenerMap = new HashMap<GraphListener, Stack<SecuredGraphListener>>();
That seems to me to read much better as:
private final Map<GraphListener, Stack<SecuredGraphListener>> listenerMap = new HashMap<>();
because the repetition of the type parameters doesn't add any real information for the reader. But you are right to point to other examples wherein the repetition is really helpful. Here are some rules of thumb (not rules to constrain the code, just helpful hints) that I would be ready to uphold:
If you are constructing an object to fill a reference as you declare it, use <>. Repeating the type parameters doesn't help anyone understand what is going on, and it can be very verbose.
Otherwise, consider how far away the declaration in question lives. If that is far enough, consider repeating the type parameters to obviate the need for readers to go back and forth in the code base.
Does that sound reasonable?
---
A. Soroka
The University of Virginia Library
> On Oct 8, 2016, at 7:45 PM, Claude Warren <cl...@xenei.com> wrote:
>
> I know that in Java 8 the old
> {code}
> Map<String> m = new HashMap<String>();
> {code}
> can now be written as
> {code}
> Map<String> m = new HashMap<>();
> {code}
> But why? I suppose in the above it is simple to figure out what is being
> constructed however if the declaration of the var and the constructor are
> separated is it not confusing? Do we have a standard/guideline for this in
> the Jena code?
>
> Suppose:
> {code}
> MyClass<String> myClass = null;
>
> // .... some lines later
>
> myClass = new MyClass<>();
> {code}
>
> makes it difficult to quickly determine the type that myClass is using.
> Perhaps I am just tilting at windmills, or am an old curmudgeon.
>
> Guidance please,
> Claude
>
> .
>
>
> --
> I like: Like Like - The likeliest place on the web
> <http://like-like.xenei.com>
> LinkedIn: http://www.linkedin.com/in/claudewarren