To share some perspective, I come from working on 200k to 500k LOC systems, with the largest (aside linux kernel drivers) being ~2M loc/20,000 cpp files. I have done my share of objc coding, much of it for my own usage. My interest in swift has to do with finding a scalable solution for client server systems where code would be shared between the two sides. Currently I do that with c# and started experimenting with phonegap&node using typescript (I share Anders Hejlsberg's view that past a few 1000 locs javascript becomes readonly). If I can appreciate that as an app-only language a number of tradeoffs are not terribly important in the long run, I question whether the same choices are equally inconsequential at the other end of the scale. I took seriously that apple will let swift become credible on the server side, but it might require that this community remembers to consider both ends of the scale when helping shape this language. I have read a lot past discussions of the last month, and I do wonder where people see this language go, and more importantly where they want to see it go. I do hope the future of swift is not just made of apps. Regards (From mobile) > On Jul 10, 2016, at 10:47 PM, Tino Heth via swift-evolution > <swift-evolution@swift.org> wrote: > > >> Should I assume then you want so much this proposal to be dropped you didn't >> even mind to look for the example so you wouldn't have to admit this >> proposal is needed? Fine, here is the whole of that example. > This list has thousands of messages, this topic alone is split into at least > six threads… I tried, but how much time should I spend searching without any > helpful hint? > But let's see what we got now... > >> I'm currently working on an app > wait a minute: An app, not a library? What difference will sealed make here > at all? > >> which will have object representations of Files and Folders (both come from >> a common class called Entry). You as a developer for this system will be >> entitled to extend from File and Entry freely but you can only work with >> Folders and its subclasses (specialised folders) but to this system it is >> important you don't subclass any type of folder. Without this proposal I >> would have to create workarounds to prevent you from doing that while still >> allowing me to subclass while playing a lot of finals everywhere. And so far >> I would have to allow you to subclass Folder itself (at least) but you would >> complain (and possibly file a bug report to me) because it would not be >> working properly because your classes would not benefit from the workaround. >> In this case, if I could subclass internally but prevent you from doing it, >> you could complain I'm not allowing you to do whatever you want but you >> wouldn't complain my code doesn't work properly (it does, you just won't >> know it). > So, how many types of directories may exist that you would have to mark as > final? (serious question — please don't ignore it) > I don't know about you specific model, but for me, invisible directories and > bundles would be all I'd be worried about — and those are basically all > normal folders as well… > So, do those subclasses each have special properties? There is only a limited > set of metadata a directory can have, so I expect there is no need for > subclassing at all: Is there a special reason why it can't be a single class, > or an enum? > This may all be useless advice that doesn't work for your case — but if I > stick with the Sasquatch-metapher, this is a very blurred picture... > >> IMO libraries are to be written with intention in mind and I don't think it >> is right to use a library written to compose a PDF file to send an email >> (even if you're sending the PDF file attached, the right way to do it is by >> composition not subclassing). > How is this statement connected to the proposal? > The only way to prevent misuse of software is not to write it; and what harm > is done to you as the author of a PDF-lib (btw: been there, done that — nasty > format ;-) if some stupid user turns your composer into Emacs? > >> Additionally, someone mentioned and I went in to check about a >> recommendation for Java to intentionally document and enable classes to be >> subclasses explicitly otherwise forbid it at all and that recommendation >> seems to come from Oracle itself. I believe Oracle would do it to Java if it >> had great interest in it without consulting anyone's opinion. > good point… Oracle is widely known for its instinctive knowledge about the > needs and problems of their customers — which they than tend to ignore and do > something different ;-) > >> About the addition to the proposal to enable force unsealing, I'm completely >> opposed as it is just like not having any of this protection at all (why >> putting a lock on the door to your house if the key is under the mat?) > As long as we don't speak about commercial libraries, which are a curiosity > in the Swift-cosmos: > There is no lock, there is not even a door — there is only a tiny sign that > says "please don't enter", and the worst thing that could happen if you > ignore it is that the original owner stops doing the housework. > >> If I'm not wrong at least one member of the core team already mentioned in >> this thread this is completely aligned with the intention of the language, >> so I think we should give it a go and stop trying to have/keep control of >> everything we touch. > Isn't this exactly what this proposal is about? Replacing freedom with > control? Stop trying to keep control of everything is actually a good idea in > the light of this proposal. > > I appreciate that you described your case, but it didn't do anything to > convince me. > > Tino > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
