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

[Howard Lovatt]

@David,

As an aside: I think that iterator is a bad example because iterator itself
is undefined as to whether it is single or multi pass. In Java the two
concepts are seperate; an iterator is always multi pass and a stream is
maybe multi pass but is treated as single pass unless you are really sure
it is multi pass (it generates a runtime error if it is single pass and you
attempt twice). This is probably a better approach and in Swift terms it
would be sequence.iterator and sequence.stream() (to remind you that stream
is probably single pass).

Back to the main topic: If we take reverse as an example then I think
sequence.reverse() reads well because you cannot iterate twice.

On 28 January 2016 at 16:46, David Waite <david at alkaline-solutions.com>
wrote:

>
> > On Jan 27, 2016, at 9:48 PM, Howard Lovatt <howard.lovatt at gmail.com>
> wrote:
> >
> > I would have no such qualms. To me array.iterator reads better that
> array.iterator().
>
> I’d make the same argument as I did before for reverse(), except in this
> case the generator mutates state indirectly (the results of next() on two
> generators returned from the same sequence are not defined to be similar)
>
> > There is precedence for this approach also; Scala. In Scala they go even
> further, if you declare a function with no args you can always call it
> without brackets. This works well in Scala and mixes well with their
> properties that are very similar to Swift properties (though different
> syntax).
>
> Not surprising considering Scala’s functional influences. In a pure
> functional system, no input to a function means something is a constant.
>
> In Ruby, the pattern to only really require parens to disambiguate an
> expression. The language allows ‘!’ to be used in a method signature to
> remind developers of side effects (or to disambiguate a non-mutating
> version, e.g. String#capitalize vs capitalize!)
>
> This has been overloaded somewhat to indicate methods which would be
> expected to mutate and return a result are instead mutating and raising an
> exception on failure (e.g. ActiveRecord::Base#save vs save!)
>
> -DW




-- 
  -- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160128/ddd7fafc/attachment.html>