Regards (From mobile)
> On Jul 17, 2016, at 8: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. > > 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. > I thought I had clearly shared my personal view (not any truth) in the other thread. IMVHO Type<T> is ill-prepared for addressing the topic of reflection. Some of the ideas are there of course simply because it is obvious that swift currently has a gap in this area and some of the pieces of a reflection API are obvious in nature. But the proposal does not propose a cohesive vision of which Type<T> would be a small step, paving the way for the rest being additive later. When dealing with reflection, the first step should IMHO be to understand the 2 facets it takes (there is plenty of literature and research papers on the topic) to give a frame of reference to the solution, and then proceed with the code that will deliver the solution. Starting from the ground up with a single class and saying 'the rest will organize itself around' is asking a lot out of lady luck, and has a very high chance of creating more 'oops we didn't think about that' moments like recently happened with 0111 a week ago, or with other proposals hitting snags at the implementattion stage. This is not unlike what happened with Any<P,Q> and all the subsequent debating.. I had offered early on that before fixating on the downstream details, a fundamental question had to be answered: whether or not to carry the semantic on a container, versus expressing it directly in the grammar. Any possible detailed syntax would just be the materialization of either of these two core choices. Instead of answering this question first -it has to do with the fundamental feel or the language, as well as deep implications for the compiler, and as such could only be answered by the core team- weeks of banter went on for no valuable outcome. IMHO this is even critical for the design of a reflection API, and i have no desire to participate in was I see as improductive without the core team making the early decisions they only can make. > > > -- > 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
