[swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)
dabrahams at apple.com
Sat Jan 30 21:57:32 CST 2016
on Sat Jan 30 2016, Joseph Lord <swift-evolution at swift.org> wrote:
> On 27/01/2016 23:50, Dave Abrahams via swift-evolution wrote:
>> on Wed Jan 27 2016, Howard Lovatt <howard.lovatt-AT-gmail.com> wrote:
>>> I would say that if it doesn't have arguments and doesn't mutate then it
>>> should be a property, since it will read better and is flexible (you can
>>> switch between a stored and calculated property without affecting the
>>> external interface easily).
>> We had at least one member of the guidelines group initially felt *very*
>> strongly that we should use (basically) that criterion. But then, in
>> our survey of the standard library, we found that applying it left us
>> with many properties that he wasn't comfortable with, such as
>> `sequence.iterator` (today's `sequence.generate()`).
> I think that if you get a new instance of something back that will be
> distinct from the one you will get if you access it again then it
> should be a method and not a property. In a way the state has changed
> because it won't give you the same instance. This would keep
> generate() in the method category (for single use ones anyway).
Well, that's roughly why we have iterator() (neé generate()) as a
method. It's a little subtler than that, though; you really need to ask
whether it's *significant* that you get a distinct instance. In the
case of iterator(), it is. Some properties may produce equivalent but
technically-distinct instances, and I don't think that's a problem.
More information about the swift-evolution