[swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)

[Dave Abrahams]

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.

-- 
-Dave