You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Jeremy Daggett <je...@RACKSPACE.COM> on 2014/07/09 18:29:06 UTC
Primitive types in APIs?
Hi devs,
I have noticed a mix of the types returned by many of the APIs in the jclouds codebase and need your help. How do others feel about standardizing on returning primitive types, versus object types for all APIs:
boolean someMethod(); ? <- Most APIs return primitives
Boolean someMethod(); ?
This has come to my attention while unasyncing the Nova APIs. We need the APIs to be consistent. How do others feel about making a decision to go with one or the other?
/jd
RE: Primitive types in APIs?
Posted by Zack Shoylev <za...@RACKSPACE.COM>.
I think there are some edge cases where this might be problematic.
Say you get a resource JSON back from a service and deserialize it into an object, where certain domain object fields have not been returned by the service (someField not included in the response).
Then boolean getSomeField() should return null, but it can't. Right?
________________________________________
From: Jeremy Daggett [jeremy.daggett@RACKSPACE.COM]
Sent: Wednesday, July 09, 2014 11:59 AM
To: dev@jclouds.apache.org
Subject: Re: Primitive types in APIs?
No particular reason, just for consistency. ;)
On 7/9/14, 9:40 AM, "Andrew Phillips" <ap...@qrmedia.com> wrote:
>> We need the APIs to be consistent.
>
>Any particular technical reason for this? Personally, I would be
>tempted to say "boolean" when it can't be null, and @Nullable Boolean
>otherwise, but that's just a somewhat context-free style preference.
>
>ap
RE: Primitive types in APIs?
Posted by Zack Shoylev <za...@RACKSPACE.COM>.
I was more concerned about domain objects that might contain large numbers of optional elements. It seems such cases would need either Optional or @Nullable?
________________________________________
From: Andrew Phillips [aphillips@qrmedia.com]
Sent: Wednesday, July 09, 2014 3:39 PM
To: dev@jclouds.apache.org
Subject: RE: Primitive types in APIs?
> Also, while 3 valued logic is great, it isn't supported that well in
> Java (until Some/None/Option in Java 8, which helps some).
jclouds is quite fond of Guava's Optional, but at the API level we
mainly use it to allow access to extension APIs that are, well,
optional.
I'd agree that we don't really want Optional<...> as a return type for
API calls that return a primitive value.
Thanks for the input, Martin!
ap
RE: Primitive types in APIs?
Posted by Andrew Phillips <ap...@qrmedia.com>.
> Also, while 3 valued logic is great, it isn't supported that well in
> Java (until Some/None/Option in Java 8, which helps some).
jclouds is quite fond of Guava's Optional, but at the API level we
mainly use it to allow access to extension APIs that are, well,
optional.
I'd agree that we don't really want Optional<...> as a return type for
API calls that return a primitive value.
Thanks for the input, Martin!
ap
RE: Primitive types in APIs?
Posted by Martin Smith <ma...@RACKSPACE.COM>.
Howdy all,
Also, while 3 valued logic is great, it isn't supported that well in Java (until Some/None/Option in Java 8, which helps some). It is also common to use checked exceptions as a 3rd value, but that also has its perils, in my opinion [1].
As mostly a user of JClouds, I'd prefer a runtime exception and primitive return types.
Cheers,
[1] http://blogs.atlassian.com/2011/05/exceptions_are_bad/
Martin B. Smith, martin.smith@rackspace.com
Direct: 210-312-3274 | Toll Free: 800-961-4454
5000 Walzem Rd. | San Antonio, TX 78218
Rackspace - the open cloud company
Ask about our DevOps Automation Service - www.rackspace.com/devops
________________________________________
From: Ignasi Barrera [nacx@apache.org]
Sent: Wednesday, July 09, 2014 2:48 PM
To: dev@jclouds.apache.org
Subject: Re: Primitive types in APIs?
I generally prefer using primitives where possible, and even more in return
types (what does a returned null mean?). Using primitives is in general
easier for client applicarions and provide more clear semantics.
I really think that avoiding nulls [1] is an extremely helpful practice and
we should apply it in our public interfaces, so I prefer using primitives
and avoid using nullable objects.
I.
[1]
https://code.google.com/p/guava-libraries/wiki/UsingAndAvoidingNullExplained
El 09/07/2014 21:28, "ssivikt@gmail.com" <ss...@gmail.com> escribió:
> and... there is a such thing as " Three-valued logic" which can be
> handful some cases, so I think API should care about semantics...
>
> On 07/09/2014 07:59 PM, Jeremy Daggett wrote:
>
>> No particular reason, just for consistency. ;)
>>
>> On 7/9/14, 9:40 AM, "Andrew Phillips" <ap...@qrmedia.com> wrote:
>>
>> We need the APIs to be consistent.
>>>>
>>> Any particular technical reason for this? Personally, I would be
>>> tempted to say "boolean" when it can't be null, and @Nullable Boolean
>>> otherwise, but that's just a somewhat context-free style preference.
>>>
>>> ap
>>>
>>
> --
> Thanks,
> Serj
>
>
Re: Primitive types in APIs?
Posted by Ignasi Barrera <na...@apache.org>.
I generally prefer using primitives where possible, and even more in return
types (what does a returned null mean?). Using primitives is in general
easier for client applicarions and provide more clear semantics.
I really think that avoiding nulls [1] is an extremely helpful practice and
we should apply it in our public interfaces, so I prefer using primitives
and avoid using nullable objects.
I.
[1]
https://code.google.com/p/guava-libraries/wiki/UsingAndAvoidingNullExplained
El 09/07/2014 21:28, "ssivikt@gmail.com" <ss...@gmail.com> escribió:
> and... there is a such thing as " Three-valued logic" which can be
> handful some cases, so I think API should care about semantics...
>
> On 07/09/2014 07:59 PM, Jeremy Daggett wrote:
>
>> No particular reason, just for consistency. ;)
>>
>> On 7/9/14, 9:40 AM, "Andrew Phillips" <ap...@qrmedia.com> wrote:
>>
>> We need the APIs to be consistent.
>>>>
>>> Any particular technical reason for this? Personally, I would be
>>> tempted to say "boolean" when it can't be null, and @Nullable Boolean
>>> otherwise, but that's just a somewhat context-free style preference.
>>>
>>> ap
>>>
>>
> --
> Thanks,
> Serj
>
>
Re: Primitive types in APIs?
Posted by "ssivikt@gmail.com" <ss...@gmail.com>.
and... there is a such thing as " Three-valued logic" which can be
handful some cases, so I think API should care about semantics...
On 07/09/2014 07:59 PM, Jeremy Daggett wrote:
> No particular reason, just for consistency. ;)
>
> On 7/9/14, 9:40 AM, "Andrew Phillips" <ap...@qrmedia.com> wrote:
>
>>> We need the APIs to be consistent.
>> Any particular technical reason for this? Personally, I would be
>> tempted to say "boolean" when it can't be null, and @Nullable Boolean
>> otherwise, but that's just a somewhat context-free style preference.
>>
>> ap
--
Thanks,
Serj
Re: Primitive types in APIs?
Posted by Jeremy Daggett <je...@RACKSPACE.COM>.
No particular reason, just for consistency. ;)
On 7/9/14, 9:40 AM, "Andrew Phillips" <ap...@qrmedia.com> wrote:
>> We need the APIs to be consistent.
>
>Any particular technical reason for this? Personally, I would be
>tempted to say "boolean" when it can't be null, and @Nullable Boolean
>otherwise, but that's just a somewhat context-free style preference.
>
>ap
Re: Primitive types in APIs?
Posted by Andrew Phillips <ap...@qrmedia.com>.
> We need the APIs to be consistent.
Any particular technical reason for this? Personally, I would be
tempted to say "boolean" when it can't be null, and @Nullable Boolean
otherwise, but that's just a somewhat context-free style preference.
ap