On Sun, Jul 17, 2016 at 1:42 PM, Jose Cheyo Jimenez <[email protected]> wrote:
> > > On Jul 16, 2016, at 11:16 PM, Xiaodi Wu via swift-evolution < > [email protected]> wrote: > > On Sun, Jul 17, 2016 at 1:07 AM, Adrian Zubarev via swift-evolution < > [email protected]> wrote: > >> My first draft had some mistakes related access modifier on extension but >> the final proposal does fully understands how they work and aims to >> eliminate default access modifier behavior. >> >> There is no default access modifier on other types like classes etc. So >> why should there be any on extensions I’d ask you. The Swift folks here >> were just whining and arguing with their laziness on typing out and >> repeating access modifier on each extension member. >> >> Jordan was in favor of removing them completely, but argued that “he >> knows some people that would still want the default access modifier to >> be there.” >> >> Right now access modifier on extensions are an ugly shake from how they >> work with protocols combined with access modifier of classes etc. (On >> protocols they just like default access modifier, but you cannot override >> them member wise.) >> >> I didn’t want to remove them completely, but allow to set the visibility >> boundary to the outside world. >> >> - public extension - visible to everywhere. >> - internal extension - member cannot be public and therefore the >> implementation is only visible for the whole module. >> - private/fileprivate extension - the extension member are only >> visible to the current file. >> >> And yes with this model you’d need to repeat correct access modifier >> member wise, but some folks already do that with extensions and everyone >> does it with classes, structs and enums. >> >> Again that concept is not about being able to refer to extensions. It’s >> about the visibility boundary set by their access modifier, which is also >> bounded by the access modifier of the extended type in respect with the >> protocol conformance that might be applied on that extension. >> > > Well, let's see if my draft gains traction. I hope it addresses some/most > of these concerns of yours. I'm trying to incorporate all of the feedback I > got today and hopefully will have something improved by tomorrow. > > > I don't think it would be good thing to propose (even as an alternative), > the complete removal of access modifiers again in a new proposal. > I have been swinging back and forth about whether removal should be the proposed solution; right now, I'm leaning again towards your view (i.e. that it shouldn't be the proposed solution, because it gets rid of some features that people like which aren't doing harm). I would expect that it should show up as an alternative because, well, it is an alternative. We should have a formal paper trail of the design alternatives explored and reasons why the community and core team accept or reject them; otherwise, it could come up again. A better approach would be to cut to the heart of the issue (public access > modifier) and cut the scope to the smallest possible subset requirements to > make that work. I do think we need to be able to declare some things with a > higher access modifier inside extensions (even though their effective scope > will be less) in order to make `private extension` work with implicitly > internal methods that effectively have fileprivate access. > Right, I will limit the proposal to those two issues. > I think this new proposal will definitely would have a better chance of > acceptance by keeping extension in making all methods inside the extension > to be internal and still force public method to be explicit like everywhere > else. > Great. I will aim to complete a revised draft this evening. > > If someone don’t get my intension right, I’m sorry for that. I’m a >> programmer not a book author and I can’t write something spectacular >> looking arguments like Mr. Mihalkovic does. >> >> That said, thats not related to your first comment about Type<T>, nor it >> does help here anyone. I feel like I’m reading philosophical books when >> reading comments that don’t have a clear answer on a particular >> topic/question. It’s more like wrapping the topic around with some flowers. >> >> >> >> -- >> Adrian Zubarev >> Sent with Airmail >> >> Am 17. Juli 2016 um 05:30:28, L. Mihalkovic ([email protected]) >> schrieb: >> >> >> Regards >> (From mobile) >> >> On Jul 16, 2016, at 9:35 PM, Adrian Zubarev via swift-evolution < >> [email protected]> wrote: >> >> Wrong thread ;) If you think it’s ill-prepared than provide some feedback >> instead of just watching and waiting to throw negative feedback during >> review process. >> >> There is a lot done, but it’s not visible to the public thread yet. Will >> be soon (by tomorrow I’d guess). >> >> Thanks. >> >> >> A question i regularly ponder on with modern opensource is how it went so >> fast from stallman writting gcc to today's anything-goes, where there seems >> to be an expectatation that throwing even the worst unfinished piece of >> code in the public should implicitely gag others, and only compel them to >> have to fix it. >> There has always been great as well as ludicrous ideas in the history of >> mankind, and it would be a rare privilege of the opensource movement that >> the latter ought not to be singled out as such, and have them become by >> their mere presence in the public, everyone's responsibility to improve >> upon. >> This proposal was based on a lack of understanding of extensions. My >> understand of the process is that the initial discussion phase is there to >> evaluate an idea leaving, only the promissing ones reach proposal stage. >> >> >> >> -- >> Adrian Zubarev >> Sent with Airmail >> >> Am 16. Juli 2016 um 21:21:59, L. Mihalkovic ([email protected]) >> schrieb: >> >> To me this is reminicent of what is happening with the T.Type / Type<T> >> story, where there seems to be a rush to throw a proposal under the cut-off >> date even if it is ill-prepared, or based on misunderstandinds. >> Regards >> (From mobile) >> >> On Jul 16, 2016, at 7:15 PM, Adrian Zubarev via swift-evolution < >> [email protected]> wrote: >> >> I tried to tackle the ability to write extensions where everyone would be >> forced to write access modifier on member level. That’s what I had in my >> mind all the time. But the respond on this was, as you can see purely >> negative. :D >> >> Making all extensions public when there is protocol conformance makes no >> sense, because you could extend your type with an internal protocol, or the >> extended type might be not public. >> >> Anyways, I’m withdrawing this proposal. :) >> >> >> -- >> Adrian Zubarev >> Sent with Airmail >> >> Am 16. Juli 2016 um 19:09:09, Paul Cantrell ([email protected]) schrieb: >> >> Because of all this, I have stopped using extension-level access >> modifiers altogether, instead always specifying access at the member level. >> I would be interested in a proposal to improve the current model — perhaps, >> for example, making “public extension” apply only to a protocol >> conformance, and disabling access modifiers on extensions that don’t have a >> protocol conformance. >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
