Empty array or nil

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Empty array or nil

Thomas Wetmore
I've now ported quite a few thousand lines of C and Objective-C to Swift, enough to detect
patterns. I've tried out coding conventions and so on. I've rejected many and kept a few.

One issue has come up frequently enough to bang me on the head the threshold number
of times to make itself known.

I have gotten very used to optionals now, as they really become a major part of your coding
life with Swift. And many of the methods I have written return optionals to good effect.

But what about methods that should return arrays of objects, and when called, a particular
execution has no objects to return in the array. In this case the programmer has the option to
return either an empty array or to return nil. Looking through my code I discover that I
am doing both with little discrimination as to which is the better (or at least consistent)
approach.

But I like consistency. So I've been going back through and converting all my:

func method (...) -> [SomeType]

methods into

func method (...) -> [SomeType]?

methods. Of course I could go the other way. One criteria I like to use is to choose the
approach the minimizes the number of lines of code that need to be written. It is still
not clear to me which solution meets this criteria better. After a few more thousand lines
of code that may be clearer.

Anyone else come across this issue and willing to share thoughts?

Tom in Massachusetts

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/89ef032f-0af9-4ba3-8d00-11cd74a0a5cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Empty array or nil

Thomas Wetmore
And I should say that another criteria I use is to select the approach that minimizes the number
of objects that must be allocated on the heap. This also argues for the [SomeType]? approach.

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/598eeae6-84f5-45ea-93f4-7910be0d7211%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Empty array or nil

Jens Alfke

On Aug 2, 2014, at 5:14 AM, Thomas Wetmore <[hidden email]> wrote:

And I should say that another criteria I use is to select the approach that minimizes the number
of objects that must be allocated on the heap. This also argues for the [SomeType]? approach.

That depends on the implementation of arrays. It’s possible, I think, that a empty array could have no heap-based component, since arrays are now passed by value. (For example, an array reference might be a {length, pointer-to-first-element} structure, where an empty array is {0, NULL}.)

Has anyone deciphered the current array implementation’s data structures?

—Jens

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/BD399C14-6EAA-4FF1-B2DC-A6AF6570EEB0%40mooseyard.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Empty array or nil

Garth Snyder
In reply to this post by Thomas Wetmore
I suspect that in the great majority of cases, worrying about the overhead of allocating an empty array is a form of premature optimization. 

Even in genuinely performance-critical code, you could return a statically-defined empty array in the case that there are no results. So overall, I'd be inclined to just ignore performance implications. Getting the API right is more important.

Given that, I would avoid returning a nil optional unless that case represents a genuinely distinct situation or result. It shouldn't simply be a stand-in for an empty array. An empty array represents itself just fine.

If you anticipate that callers will have separate code paths for the zero-elements case, you might consider reifying that in the API. For example, if the leaf nodes of a graph are likely to receive special treatment, define an isLeafNode() method rather than making the client call childNodes() and check the length of the returned array.

Garth

On Aug 2, 2014, at 5:08 AM, Thomas Wetmore <[hidden email]> wrote:

...what about methods that should return arrays of objects, and when called, a particular
execution has no objects to return in the array. In this case the programmer has the option to
return either an empty array or to return nil...

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/87DCB68A-7DBF-4A74-8442-3A7ABCB5685A%40garthsnyder.com.
For more options, visit https://groups.google.com/d/optout.