Oops, correction: @unshelter<Wotsits>(self); or @unshelter<Wotsits>(aWotsit) // Inside a Wotsit or a Wotsit subclass this would work, y becomes available.
Should be: @unshelter<Wotsits>(aThing) // Inside a Wotsit or a Wotsit subclass this would work, y becomes available. On Mon, 17 Oct 2016 at 13:38 Jay Abbott <[email protected]> wrote: > I'm not sure of my own opinions on this one as I can see good points on > both sides. There also seem to be a variety of different discussions with > similar concerns. So at the risk of confusing things I'm suggesting another > idea, with the hope/intention of promoting some deeper thought and helping > us figure out what is needed/wanted. > > I will use the word 'sheltered' here, apologies if that is confusing, it > just means protected/hidden/whatever but without any existing notions of > what those might mean. It might not be the best word either, I just picked > it from a list of synonyms for 'protected'. > > Class authors can (now) if they want provide their own way to explicitly > access some private members through a public interface: > > public class Thing { > private var x: Int > public var shelteredX: Int { > get { return x } > set { x = newValue } > } > } > > But this isn't ideal as it just causes excess boilerplate code and doesn't > hide it from anyone or suggest they shouldn't normally use it (other than > the explicit naming). However, perhaps the compiler could help with this > type of pattern as follows: > > public class Thing { > sheltered var x: Int { > get { return x } // not sure how this would work - x is also the > backing ivar so you don't have to declare it twice as _x and x. > set { x = newValue } > } > // accessors provided - internal access to x is direct, sheltered > access is via accessors > > sheltered var y: Int > // No accessors provided, sheltered access to y is direct > } > > For members with 'sheltered' access: > * Don't by default allow access to the sheltered members or accessors - > they are equivalent to private (or maybe fileprivate) > * Provide a way to expose them in a given scope > * I think it can be applied to methods too > > For example: > var aThing = Thing() > aThing.x = 7 // NOT ALLOWED: x is sheltered. > @unshelter(aThing) // aThing is unsheltered in the remainder of its scope. > aThing.x = 7 // NOW ALLOWED > > One good thing is that this is very explicit where you use it. > > Sheltered groups might also be a thing: > > Definition: > sheltered<Subclasses> var x: Int > sheltered<Wotsits> var y: Int > Usage: > @unshelter<Subclasses>(aThing) > // x is available, y isn't > @unshelter<Subclasses, Wotsits>(aThing) > // x and y are available > > "Subclasses" and "Wotsits" are author-defined identifiers, not keywords. > This is a bit like friends and protected, but using an honesty system, > where friends can easily declare themselves as friends by unsheltering all > the Wotsits group, and subclasses (not enforced) would unshelter the > Subclasses group. That is, the author's intentions are clear, but other > classes can abuse it to get access. If the author doesn't want to allow > abuse, they can do this: > > Definition: > sheltered<Subclasses: Thing> var x: Int > sheltered<Wotsits: Wotsit> var y: Int > > Usage: > @unshelter<Subclasses>(self); or > @unshelter<Subclasses>(anOtherThing) > // Works inside a Thing subclass, x becomes available. The scope in which > @unshelter is used must match the type of the shelter group. > > @unshelter<Wotsits>(self); or > @unshelter<Wotsits>(aWotsit) > // Inside a Wotsit or a Wotsit subclass this would work, y becomes > available. > > I'm just spitballing here, this isn't fully thought through. Perhaps a > where clause would be better instead of a type annotation for the shelter > groups, so you could list multiple types that are allowed to unshelter that > group. You might be able to abuse it still by putting something in an > extension of an allowed class, so that may need some further thought. > > This is of course more complex that other proposed solutions, I'm just > trying to combine all the desires people seem to have and see what people > think - do we want more control and are happy with a bit more complexity? > or should it be simple and less control? Personally I actually don't have > much of an opinion on it because I haven't used Swift enough yet to come a > cropper of such things. > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
