[swift-evolution] [Review] Require self for accessing instance members

[Francisco Costa]

I think most of what has been said in favor of explicit `self` is valid to
some degree, however I think it is a matter of _code style_ that should be
considered by each team. If there is indeed a clear benefit in using it, it
will certainly become idiomatic over time. Personally, I think this is some
verbosity that we can live without.

Francisco


On Fri, Dec 18, 2015 at 12:33 AM, David Hart via swift-evolution <
swift-evolution at swift.org> wrote:

> Hi people,
>
> I've tried to avoid interacting with the discussions here and on Twitter
> because all the good arguments on both sides of the fence seem to have been
> given and that it would just add more fuel to what seems like a pretty hot
> fire :)
>
> But I'd like to move the discussion forward. I've I'd have to summarize
> all of it, it seems like they are people who like the implicitness of self
> and REALLY don't like my proposal, because it would induce a heavy writing
> and reading cost to code which looks fine to them.
>
> On the other hand, there are people like me who already use self
> explicitly to help document the scope of variables used and where there
> might be hidden side effects of getters and setters, and really appreciate
> he advantages it brings. It seems that we would enjoy a language that
> forces explicitness to be able to read code everywhere and be able to make
> the same assumptions.
>
> But it seems that we all agree with the underlying issue: that the fact
> that the neither the language, nor the code conventions, nor the compiler
> makes it extremely clear about the scope of variables at the point of use
> as other languages might (Ruby comes to mind).
>
> We just seem to disagree on explicit self being the solution: it adds a
> lot of verbosity for people who prefer succinctness (even if I think it is
> a less important goal).
>
> What other solutions can we think up? We already discussed using other
> prefix keywords which are less verbose than self, but couldn't come up with
> any great solution. I would just like the language help us here to make
> things safer without everybody using their own naming conventions or
> Hungarian notation.
>
> David
>
> PS: I haven't found time to update the proposal and I'd like to apologize
> if it sounded a bit too much one sided - I wrote it before a lot off e nag
> give feedback, and tried to stick to the style of other proposals, but
> perhaps failed in doing so.
>
>
> On 17 Dec 2015, at 23:38, Rudolf Adamkovic via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> After careful reading through all the arguments, I'm now in the -1 camp
> too.
>
> The "visual noise" examples and reasoning about consistency with the rest
> of the language totally got me.
>
> P.S. I really liked the idea to use a dot instead of dot self but yeah,
> dot is already reserved for enums.
>
> R+
>
> Sent from my iPhone
>
> On 16 Dec 2015, at 19:55, Douglas Gregor via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Hello Swift community,
>
> The review of “Require self for accessing instance members” begins now and
> runs through Sunday, December 20th. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a change
> to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have you used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Cheers,
> Doug Gregor
> Review Manager
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151218/f50dff8e/attachment.html>