Should a queue be value type or reference type?


(晓敏 褚) #1

I'm wondering the type of queues. If I want it to be like the dispatch queues, it should be reference type since we care about the object identity. But if I view it simply as a collection of elements, it should be value type. So what should it be, according to API design guidelines?

Schurin Chu


(Quinn “The Eskimo!”) #2

It’s hard to answer this question without more information about your specific context. However, I think it’s safe to say that Swift expresses a preference for value types. OTOH, reference types exist for a reason: sometimes you really do want to model shared mutable state.

My approach to this is to design the data structure as a value type and see how that works out for clients. If the client code looks good, you’re set. OTOH, if the client code is painful, you need to rethink.

Share and Enjoy

···

On 25 Jul 2016, at 15:10, 褚 晓敏 via swift-users <swift-users@swift.org> wrote:

So what should it be, according to API design guidelines?

--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware


(Kwame Bryan) #3

As Quinn said, this is a hard question to answer. As Dave said in wwdc 15.
Will you make comparisons over your collection. There's great examples of
how you can do this. Unfortunately, without a usecase. This response is
philosophical.

···

On Jul 26, 2016 3:37 AM, "Quinn "The Eskimo!" via swift-users" < swift-users@swift.org> wrote:

On 25 Jul 2016, at 15:10, 褚 晓敏 via swift-users <swift-users@swift.org> > wrote:

> So what should it be, according to API design guidelines?

It’s hard to answer this question without more information about your
specific context. However, I think it’s safe to say that Swift expresses a
preference for value types. OTOH, reference types exist for a reason:
sometimes you really do want to model shared mutable state.

My approach to this is to design the data structure as a value type and
see how that works out for clients. If the client code looks good, you’re
set. OTOH, if the client code is painful, you need to rethink.

Share and Enjoy
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users


(Jordan Rose) #4

Rather than look for an answer in the API design guidelines, try choosing between value and reference semantics. If you pass the queue to another part of the program, and that other part of the program pops some things off of it, should that change be reflected in the original queue? Or would you expect passing the queue somewhere to make a completely independent copy? As you say, DispatchQueue clearly works the first way (and should), and Array works the second way (and should). What should your type do, in your application?

One more note: it’s easier to go from value semantics to reference semantics, by making the value be a property of a class instance. So if you make a value-typed queue, you could use it to implement DispatchQueue.

Hope we’ve given you some places to start.
Jordan

···

On Jul 26, 2016, at 00:36, Quinn The Eskimo! via swift-users <swift-users@swift.org> wrote:

On 25 Jul 2016, at 15:10, 褚 晓敏 via swift-users <swift-users@swift.org> wrote:

So what should it be, according to API design guidelines?

It’s hard to answer this question without more information about your specific context. However, I think it’s safe to say that Swift expresses a preference for value types. OTOH, reference types exist for a reason: sometimes you really do want to model shared mutable state.

My approach to this is to design the data structure as a value type and see how that works out for clients. If the client code looks good, you’re set. OTOH, if the client code is painful, you need to rethink.