> On Jun 12, 2016, at 4:05 PM, Thorsten Seitz <tseit...@icloud.com> wrote: > >> >> Am 12.06.2016 um 09:21 schrieb L. Mihalkovic <laurent.mihalko...@gmail.com >> <mailto:laurent.mihalko...@gmail.com>>: >> >> >> >> >> Regards >> (From mobile) >> On Jun 11, 2016, at 11:43 PM, Thorsten Seitz <tseit...@icloud.com >> <mailto:tseit...@icloud.com>> wrote: >> >>> >>> >>>> Am 11.06.2016 um 15:08 schrieb L. Mihalkovic <laurent.mihalko...@gmail.com >>>> <mailto:laurent.mihalko...@gmail.com>>: >>>> >>>> >>>>> On Jun 11, 2016, at 2:05 PM, Thorsten Seitz <tseit...@icloud.com >>>>> <mailto:tseit...@icloud.com>> wrote: >>>>> >>>>> >>>>>> Am 11.06.2016 um 12:38 schrieb L. Mihalkovic >>>>>> <laurent.mihalko...@gmail.com <mailto:laurent.mihalko...@gmail.com>>: >>>>>> >>>>>> >>>>>>> On Jun 11, 2016, at 11:30 AM, Thorsten Seitz <tseit...@icloud.com >>>>>>> <mailto:tseit...@icloud.com>> wrote: >>>>>>> >>>>>>> >>>>>>>> Am 11.06.2016 um 08:00 schrieb L. Mihalkovic >>>>>>>> <laurent.mihalko...@gmail.com <mailto:laurent.mihalko...@gmail.com>>: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> (From mobile) >>>>>>>>> On Jun 10, 2016, at 9:35 PM, Thorsten Seitz via swift-evolution >>>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Am 09.06.2016 um 19:50 schrieb Thorsten Seitz via swift-evolution >>>>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Am 09.06.2016 um 18:49 schrieb Dave Abrahams via swift-evolution >>>>>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> on Wed Jun 08 2016, Jordan Rose <swift-evolution@swift.org >>>>>>>>>>> <mailto:swift-evolution@swift.org>> wrote: >>>>>>>>>>> >>>>>>>>>>>>> On Jun 8, 2016, at 13:16, Dave Abrahams via swift-evolution >>>>>>>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> on Wed Jun 08 2016, Thorsten Seitz >>>>>>>>>>>> >>>>>>>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>>>>>>>>> <mailto:swift-evolution@swift.org >>>>>>>>>>>>> <mailto:swift-evolution@swift.org>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Ah, thanks, I forgot! I still consider this a bug, though (will >>>>>>>>>>>>>> have >>>>>>>>>>>>>> to read up again what the reasons are for that behavior). >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, but in the case of the issue we're discussing, the choices >>>>>>>>>>>>> are: >>>>>>>>>>>>> >>>>>>>>>>>>> 1. Omit from the existential's API any protocol requirements that >>>>>>>>>>>>> depend >>>>>>>>>>>>> on Self or associated types, in which case it *can't* conform to >>>>>>>>>>>>> itself because it doesn't fulfill the requirements. >>>>>>>>>>>>> >>>>>>>>>>>>> 2. Erase type relationships and trap at runtime when they don't >>>>>>>>>>>>> line up. >>>>>>>>>>>>> >>>>>>>>>>>>> Matthew has been arguing against #2, but you can't “fix the bug” >>>>>>>>>>>>> without >>>>>>>>>>>>> it. >>>>>>>>>>>> >>>>>>>>>>>> #1 has been my preference for a while as well, at least as a >>>>>>>>>>>> starting >>>>>>>>>>>> point. >>>>>>>>>>> >>>>>>>>>>> I should point out that with the resyntaxing of existentials to >>>>>>>>>>> Any<Protocols...>, the idea that Collection's existential doesn't >>>>>>>>>>> conform to Collection becomes far less absurd than it was, so maybe >>>>>>>>>>> this >>>>>>>>>>> is not so bad. >>>>>>>>>> >>>>>>>>>> I think the problem is more that Any<Collection> does not conform to >>>>>>>>>> a specific value for a type parameter T: Collection >>>>>>>>>> >>>>>>>>>> What I mean by this is that `Collection` denotes a type family, a >>>>>>>>>> generic parameter `T: Collection` denotes a specific (though >>>>>>>>>> unknown) member of that type family and `Any<Collection>` denotes >>>>>>>>>> the type family again, so there is really no point in writing >>>>>>>>>> Any<Collection> IMO. >>>>>>>>>> The type family cannot conform to T because T is just one fixed >>>>>>>>>> member of it. >>>>>>>>>> It conforms to itself, though, as I can write >>>>>>>>>> let c1: Any<Collection> = … >>>>>>>>>> let c2: Any<Collection> = c1 >>>>>>>>>> >>>>>>>>>> That’s why I think that we could just drop Any<Collection> and >>>>>>>>>> simply write Collection. >>>>>>>>> >>>>>>>>> >>>>>>>>> Let me expand that a bit: >>>>>>>>> >>>>>>>>> Actually all this talk about existentials vs. generics or protocols >>>>>>>>> vs. classes has had me confused somewhat and I think there are still >>>>>>>>> some misconceptions present on this list sometimes, so I’ll try to >>>>>>>>> clear them up: >>>>>>>>> >>>>>>>>> (1) misconception: protocols with associated types are somehow very >>>>>>>>> different from generics >>>>>>>>> >>>>>>>>> I don’t think they are and I will explain why. The only difference is >>>>>>>>> the way the type parameters are bound: generics use explicit >>>>>>>>> parameter lists whereas protocols use inheritance. That has some >>>>>>>>> advantages (think long parameter lists of generics) and some >>>>>>>>> disadvantages. >>>>>>>>> These ways are dual in a notation sense: generic types have to have >>>>>>>>> all parameters bound whereas protocols cannot bind any of them. >>>>>>>>> The „existential“ notation `Any<>` being discussed on this list is >>>>>>>>> nothing more than adding the ability to protocols to bind the >>>>>>>>> parameters to be used just like Java’s wildcards are adding the >>>>>>>>> opposite feature to generics, namely not having to bind all >>>>>>>>> parameters. >>>>>>>> >>>>>>>> btw, i tried to to see if Any<> could have a simpler alternative >>>>>>>> https://gist.github.com/lmihalkovic/8aa66542f5cc4592e967bade260477ef >>>>>>>> <https://gist.github.com/lmihalkovic/8aa66542f5cc4592e967bade260477ef> >>>>>>> >>>>>>> As you know I like using `&` as type intersection operator. But you >>>>>>> write "The syntax leave a void when it comes to expressing the so >>>>>>> called Top type:“ >>>>>>> Why? Just give the top type a name, e.g. `Any` and you are done. >>>>>> Yes.. I just don't like magic. I think that all types should be >>>>>> expressable with a syntax and that you can then decide to alias one >>>>>> parsing case with a specific name. Not the other way around. >>>>> >>>>> Well, I think that would be backwards, because we have a nominal type >>>>> system. That means that the syntax for a type is just its name. >>>> >>>> I realize we do not understand each other. >>>> The words we use now to describe a behavior are just that, words. As is >>>> the concepts they describe are useless to the computer running the >>>> compiler. >>>> So we need to map these concepts into a heuristic that a fast but dumb >>>> computer will be able to reason with. The code to do that will be either >>>> clean and organized, or it will look contrived and full of different paths >>>> that will be difficult to mesh together. Of all the possible ways in which >>>> swift can behave as a language, some will lead to the former, others to >>>> the latter code. I think this is not fate or something you find out after >>>> the decision was made and you struggle to carry it through. This is >>>> something that can partially be predicted. One of the tools for such >>>> prediction is to translate the concepts into a grammar that will show >>>> formalize the logic. The simpler the logic, the cleaner (not simple) the >>>> final code. >>>> >>>> Saying that the syntax for a type is a name is of no use whatsoever for >>>> the compiler implementer. It is so universally true that it cannot help in >>>> any way whatsoever decide the shape of the swift grammar, much less the >>>> structure of the c++ code implementing it. >>>> >>>>> `&` is a type operator which creates a new type from its operands. >>>>> `where` clauses add constraints to types. >>>>> But it all starts with a type's name. >>>>> >>>>> The only magic would be that all type definitions (`protocol` etc.) which >>>>> do not give a supertype they conform to, will implicitly conform to >>>>> `Any`, i.e. >>>> >>>> I call magic the core notions of swift that cannot be expressed in swift >>>> but have to parachutted in by the compiler. If you read Chris' initial >>>> message you will see that he said as much, that adopting P&Q as syntax was >>>> leaving a gap that the compiler would have to magically fill. >>>> >>>> >>>>> >>>>> protocol Foo { … } >>>>> >>>>> means >>>>> >>>>> protocol Foo : Any { … } >>>>> >>>>> That’s less magic than creating a special syntax just to express the top >>>>> type. >>>> >>>> I will try again... Would it be easier to understand it if instead of >>>> magic I said arbitrary? You are creating a special case: you decide >>>> arbitrarily that the special series of characters 'A' 'n' 'y' with this >>>> precise casing and without any spaces is going to be adorned with a >>>> special meaning when used in specific situations. This is not something >>>> you deduced. My approach is exactly the opposite: _[] does not describe >>>> the top type because I have a special affinity with these characters, it >>>> describes the top type because it is the only possible logical conclusion >>>> from having followed a set of rules attached to a syntax that describes >>>> ALL existentials. And because it is not particularly savory, I typealias >>>> it to something else. But this is not in the compiler, it us in the >>>> standard linrary... inside swift, not outside. >>> >>> Ok, that's a good argument. But your proposal does not contain those rules. >>> Why should _[] describe the top type? You just say this in your proposal, >>> but you do not define rules what _[] means. >>> _[A,B] >> >> don't know where this comes from. This is incorrect and the parser would >> reject it. >> >>> describes the type intersection of A and B, i.e. it contains all members of >>> A which are also members of B. _[] does not list any types, so one might >>> conclude that it has no members and therefore must be the bottom type! >> Are you saying that protocol<> is the bottom type of Swift then? Because if >> you disect the logic it follows to explain why it is a top type and apply >> the exact same reasoning to _[] then you should reach the same conclusion >> {same effects produce the same conclusions} >> >>> Or _[A,B] in reality means _[A,B,Any],i.e. A & B & Any which of course is >>> equal to A & B. Then _[] would just mean Any, but we would have had to >>> introduce the top type explicitly again. >> From cause to effects. Any is an effect (a conclusion we reach) rather than >> a cause (something we posit before starting the discussion). Like I >> explained, Any is a stdlib provided convenient typealias for _[] as opposed >> to a parachuted concept born inside the compiler. Btw, it means a different >> stdlib could redefine it as All, without altering the compiler. Any is not >> core to swift's structure, but _[] is because it is borne out of the >> mechanical uniformity of the grammar. >> >>> On the other hand if we declare a protocol Any and define protocol A {...} >>> to mean protocol A: Any {...} there is not really something special in the >>> compiler except for adding the conformance which seems very minor to me. >>> Everything else is just standard behavior of the type system. >> >> You are back to adding some magic that I just demonstrated is not required >> if the grammar is simple (not that i could add it to my grammar to please >> you, but then it would not eliminate any of the other definitions, and would >> just complicate the parser and type checker to ensure that people use it >> correctly. Per Ockham's principle, the system i describe is a better >> alternative. >> >>> >>> >>>> Read Chris' original announcement.. He describes P&Q as it would be >>>> adopted today as being just a CORNER CASE of a single general principal... >>>> a single grammar that can work today to describe P&Q as well as generalize >>>> existentials tomorrow. No special treatment, single parser, single rule. I >>>> don't like to write un-necessary IF statements in code. >>> >>> Sorry, I do not understand what you mean here: where would you have to >>> write unnecessary if-statements? >> >> Close your eyes and make a mental representation of what the code to >> implement the Any<....> proposal will necessarily look like... that is what >> I am referring to. That code cannot not be uggly. Because some of of things >> a parser typically should catch are not discernsble, and therefore have to >> be differed to the type checker. By comparison, look at the grammar I wrote >> and picture the code to implement it. The picture will look very different, >> and the parser can already eliminate a lot of things that never reach the >> type checker. >> >>> >>> >>>> >>>>>>> Why should the top type have special *syntax*? It is just the type all >>>>>>> other types conform to. No need to do something special here and >>>>>>> therefore no need to invent an alternative syntax like `Any<>` or the >>>>>>> alternative from your gist which is rather confusing IMO (and I don’t >>>>>>> like the special case given to classes in the syntax). >>>>>> The _[] case is just a degenerate case of the syntax, showing that it is >>>>>> expressible inside, as opposoed to have to define a contextual keyword >>>>>> (read the SourceKit code). And then it is aliasable. Part of the >>>>>> problems in swift today to me is that some things are no doable in >>>>>> swift, so the compiler must contain that semantic. This here is just one >>>>>> example, but there are others. These are notions that the standard >>>>>> library has to defer to the compiler. Some of them have been tabled for >>>>>> 4.0 it seems. My point here was that it is not fate, and choosing the >>>>>> syntax carefully for existentials (whichever it is, i don't really care >>>>>> inthe end) would prevent having to add a magic keyword for to top type >>>>>> to the compiler and to SourceKit again (they are trying to remove them). >>>>> >>>>> `Any` would *not* be a keyword. It is just a type name like `Collection` >>>>> or `Int`. Like I said, the only magic would be in adding `: Any` to type >>>>> definitions without a conforming clause. >>>> >>>> I hope that by now you understand what magic I was talking about. >>>> >>>>> >>>>>> >>>>>> As for the current Any<...> proposal for generalizing existentials it is >>>>>> IMHO cluncky and magic. There is nothing stopping us mechanically from >>>>>> entering Any<UITableView, UIButton>. To me that is the holemark of bad >>>>>> design. In what I tested you just can't do it and the reason is clear. >>>>>> Of course when I >>>>> >>>>> `Any<UITableView, UIButton>` is just an intersection type and would be >>>>> written UITableView & UIButton. And, yes, that would be ok, because it >>>>> would be just the empty set, i.e. the bottom type (which has no members). >>>>> There is no magic involved, it is just the normal result of an >>>>> intersection: each type is a set containing all instances of this type >>>>> (instances conforming to it) >>>> >>>> You can't be serious? You are saying that to you the ide should not be >>>> telling us we are writting an absurdity? And this one was obvious, but it >>>> gets a lot worse with more complex types. >>> >> >> Take a screenshot next time you see a "let x:Any<UITableView, UIButton>" in >> an app and send it to me. The absurdity would be for the compiler to >> generate a binary, the app to start, and us to wonder why x the code >> depending on x would never execute. Seems obvious to you why now? > > I’m taking an example from Gavin King’s presentation about Ceylon instead > which can be found here: > https://greenjug.java.net/resources/CeylonEastCoastTour20141016.pdf > <https://greenjug.java.net/resources/CeylonEastCoastTour20141016.pdf>
my understanding is that dave is the type system designer. I will let the two of you finish this conversation and just read. very best > > <PastedGraphic-1.tiff> > > Object is the abstract supertype of all types representing definite values, > i.e. which are not null. Remember that in Ceylon Optional<T> is modeled as > type union T | Null, where Null is the type containing the single member null > (i.e. nil in Swift). > Element is the type parameter for the elements of Iterable. > > Element might be String | Null, for example (in Ceylon abbreviated as String? > just like in Swift). > Element & Object can only be String, because Null & Object is empty, i.e. is > the bottom type: > > (String | Null) & Object = (String & Object) | (Null & Object) = String | > Bottom = String > > So, while you don’t see UITableView & UIButton here, there is Null & Object > at work which yields the bottom type, just like UITableView & UIButton would. > If this was forbidden, then how would the type system be able to simplify the > expression (String | Null) & Object? > >> >> not debatting past here I can't see how it relates (it is interesting but >> you may want to look at the whole thing from a 'whats usefull' perspective, >> rather than as 'whats combinatorially possible‘ > > Like the slide above hopefully demonstrated this is not just a nice > theoretical exercise but it *is* useful if you use the whole abstraction and > do not try to arbitrarily single out special cases as forbidden. > > Of course, writing UITableView & UIButton is not useful, but writing > something like T & Object is, but it needs the whole general mechanism to > work. > (And that general mechanism will show you automatically that UITableView & > UIButton is not useful, because you can’t call any method on it, *without* > having to introduce compiler magic or IDE magic to explicitly forbid this.) > > Hope that made sense now :-) > > -Thorsten > > > >> >>> Why is an empty intersection absurd? The beauty is that all type >>> expressions sort out automatically by applying simple set rules. And it >>> actually does make sense! >>> >>> struct Set<T> { >>> // answer any one element >>> func any() -> T? >>> } >>> func intersect<T, U>(a: Set<T>, b: Set<U>) -> Set<T & U> {...} >>> >>> let x: Set<UITableView> = ... >>> let y: Set<UIButton> = .. >>> let z = intersect(x, y) // has type Set<Bottom> >>> z.any // has type Optional<Bottom> and therefore can only be nil >>> >>> Therefore the type system statically knows that the intersection of those >>> sets is always empty. No need to declare this as invalid. It just works >>> correctly and gives the results you would expect without need for special >>> casing and compiler magic (which we both would like to keep small). >>> >>> -Thorsten >>> >>> >>>>> . Intersecting two sets might result in an empty set. The type denoting >>>>> the empty set is the bottom type which is the subtype of all types and >>>>> might be called `Nothing` or `Never` or `Bottom`. >>>>> Ceylon makes very nice use of type intersections and type unions and the >>>>> beautiful thing is that these type operations really just work like you >>>>> would expect if you think of types as sets (which is the standard >>>>> definition for a type AFAIK). No surprises and no magic there! >>>>> >>>>> So it is *not* a sign of bad design, quite to the contrary! What did you >>>>> test it with? Probably not Ceylon, because otherwise you would have seen >>>>> that it just works. >>>> >>>> Hey, who knows, ceylon may one day come to llvm... >>>> >>>>> >>>>> >>>>>> say you can't I do not mean that your keyboard will zap u if you try. >>>>>> But the way to verify correctness is different... and in a world where >>>>>> xcode would be a good ide, then code completion would even show you why >>>>>> and actually truly assist (because the grammar i tested makes really >>>>>> makes it possible). I know that xcode is only as good as SourceKit lets >>>>>> it be. >>>>>> >>>>>>>> >>>>>>>>> Essentially `Any<Collection>` in Swift is just the same as >>>>>>>>> `Collection<?>` in Java (assuming for comparability’s sake that >>>>>>>>> Swift’s Collection had no additional associated types; otherwise I >>>>>>>>> would just have to introduce a Collection<Element, Index> in Java). >>>>>>>>> >>>>>>>>> Likewise `Any<Collection where .Element: Number>` is just the same as >>>>>>>>> `Collection<? extends Number>` in Java. >>>>>>>> Java supports co/contra variant params >>>>>>> >>>>>>> Java has no declaration-site variance like Ceylon or Scala have (see >>>>>>> e.g. >>>>>>> http://ceylon-lang.org/blog/2014/07/14/wildcards#why_i_distrust_wildcards_and_why_we_need_them_anyway >>>>>>> >>>>>>> <http://ceylon-lang.org/blog/2014/07/14/wildcards#why_i_distrust_wildcards_and_why_we_need_them_anyway>). >>>>>>> >>>>>>> Java’s wildcards are a way to express use-site variance. The proposed >>>>>>> `Any<>` does just the same. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> And just like Collection<?> does not conform to a type parameter `T >>>>>>>>> extends Collection<?>` because Collection<?> is the type `forall E. >>>>>>>>> Collection<E>` whereas `T extends Collection<?>` is the type `T. >>>>>>>>> Collection<T>` for a given T. >>>>>>>> >>>>>>>> This picture is accurate today, but there are going to be more serious >>>>>>>> differences after 10 no date is currently geven for when it will come) >>>>>>> >>>>>>> You mean Java 10? >>>>>> >>>>>> Yes. After 10. Than is their only date hint. >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> In essence protocols with associated types are like generics with >>>>>>>>> wildcards. >>>>>>>> >>>>>>>> Yes, java has kept everything within its generics system rather than >>>>>>>> split parts out. Something people may not immediately think about with >>>>>>>> respect to the 2 generic systems is that when u call a >>>>>>>> func<T>capture(T t){} in java with a wildcard you are doing a compile >>>>>>>> time capture only (to avoid the dreaded unsafe casts), whereas it is >>>>>>>> really nice to do the same in swift and subsequently be able to access >>>>>>>> T.Type and see that it is not Any. The closest u ever get to that type >>>>>>>> at runtime in java is via generics introspection, but u still can't do >>>>>>>> everything ( like no new T() ). But today the bridging between >>>>>>>> existential types and generics is definitely a work in progress. >>>>>>>> >>>>>>>>> Coming back to the questions whether (a) allowing existentials to be >>>>>>>>> used as types is useful and (b) whether sacrificing type safety would >>>>>>>>> somehow be necessary for that, I think we can safely answer >>>>>>>>> (a) yes, it *is* useful to be able to use existentials like >>>>>>>>> Any<Collection> as types, because wildcards are quite often needed >>>>>>>>> and very useful in Java (they haven’t been added without a reason) >>>>>>>> >>>>>>>> IMO they made java 8 (referring to streams). And even though the >>>>>>>> syntax for co/contra variance is pretty heavy, it is the foundation >>>>>>>> for all modern java code. The any-fication of the generics is going to >>>>>>>> open new doors as some of it will translate into a partial reification >>>>>>>> in the jvm. It seems the decision for now is to not use the extra info >>>>>>>> in java to retain binary compatibility with all the erased code out >>>>>>>> there, this is something scala might use in areas where it won't mind >>>>>>>> loosing java compatibility. >>>>>>>> >>>>>>>>> (b) no, sacrificing type safety does not make sense, as the >>>>>>>>> experience with Java’s wildcards shows that this is not needed. >>>>>>>>> Especially if something like path dependent types is used like >>>>>>>>> proposed and some notation to open an existential’s type is added, >>>>>>>>> which is both something that Java does not have. >>>>>>>> >>>>>>>> I hope typesafe opening inside the " if let " syntax gets added. I >>>>>>>> know that chris is against sugaring, but I played if an implementation >>>>>>>> of >>>>>>>> >>>>>>>> ... x is String? >>>>>>>> If let! x {} >>>>>>>> That runs as >>>>>>>> if let x = x {} >>>>>>>> >>>>>>>> something equally short could be done here. >>>>>>>> >>>>>>>>> >>>>>>>>> (2) misconception: POP is different from OOP >>>>>>>>> >>>>>>>>> It is not. Protocols are just interfaces using subtyping like OOP has >>>>>>>>> always done. They just use associated types instead of explicit type >>>>>>>>> parameters for generics (see above). The more important distinction >>>>>>>>> of Swift is emphasizing value types and making mutation safely >>>>>>>>> available by enforcing copy semantics for value types. >>>>>>>> >>>>>>>> Values are coming to the jvm, which will narrow this gap (like their >>>>>>>> view identity for value vs ref and the whole deep ==) . I also really >>>>>>>> like the cow approach of the swift runtime. >>>>>>>> >>>>>>>>> But protocols are not really different from interfaces in Java. >>>>>>>> >>>>>>>> There is one big difference: default methods, but it seems swift will >>>>>>>> add that soon. >>>>>>> >>>>>>> Swift already has default extension methods, doesn’t it? >>>>>> >>>>>> Yes, and no. It has differently dispatched code that can be found to >>>>>> fill in the gap of the conformance req, yes. But Joe Grof (?) said that >>>>>> there are no reasons why these could not be added. Having true defaults >>>>>> could be one way to deal with optional comformance… >>>>> >>>>> The dispatch issue only arises for extensions introducing a method that >>>>> is not declared in a protocol. That is something you *cannot* do in Java. >>>>> Java’s default methods are implementations for methods declared in >>>>> interfaces. Swift’s extension methods providing defaults for methods >>>>> declared in a protocol are dynamically dispatched and should work like >>>>> Java’s default methods. >>>> >>>> I think we should agree to disagree. >>>> >>>> >>>>> (One caveat exists with subclasses where the superclasses didn’t >>>>> implement the method because I then am not allowed to `override` the >>>>> default method but that is a bug IMO). >>>>> >>>>> -Thorsten >>>>> >>>>> >>>>> >>>>>> >>>>>> protocol MyProto { >>>>>> func mustImplement() >>>>>> default canImplement() { } >>>>>> } >>>>>> >>>>>> Related data there: >>>>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018560.html >>>>>> >>>>>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018560.html> >>>>>> >>>>>>> >>>>>>> >>>>>>>> I also really like how extensions and conformance mix together in >>>>>>>> swift to bake retro-modelling in and the adapter pattern (spent enough >>>>>>>> years deep diving inside eclipse to appreciate it). >>>>>>>> >>>>>>>>> I would have preferred a unified model using just classes with real >>>>>>>>> multiple inheritance like Eiffel has and value types just being a >>>>>>>>> part of that similar to Eiffel’s `expanded` classes. But that ship >>>>>>>>> has probably sailed a long time ago :-/ >>>>>>> >>>>>>> I like extensions very much (having used Smalltalk for a long time). I >>>>>>> like enums for the pattern matching and structs as value types. But >>>>>>> having to split protocols off instead of using abstract classes makes >>>>>>> things more complicated IMO. >>>>>>> >>>>>>>> -1 i am old school c/c++... i really like protocol, struct, class, >>>>>>>> extensions, enums. It is a really nice mix that gives objc people room >>>>>>>> to grow, but I do miss how they are an integral part of generics (i >>>>>>>> protocols as a replacement and look forward to when they interact >>>>>>>> better) and namespaces+scoped-imports (c#)... Looking forward to where >>>>>>>> things go next >>>>>>> >>>>>>> Yeah, namespacing/submodules/conflict resolution (when doing imports >>>>>>> but also when conforming to multiple protocols which has just the same >>>>>>> problems) are still missing. But I’m optimistic :-) Let’s complete >>>>>>> generics first, then tackle existentials/type intersections. >>>>>> >>>>>> I think I care more about existentials, but only because of the kind of >>>>>> java i wrote for a living. I just looked at a bunch of opensource swift >>>>>> libs (particularly for server side swift)... some of it is a real >>>>>> engineering disaster: 20+ folders, each with 2 source files... or 3 >>>>>> folders "extensions" "utils" "classes". Swift is currently not equiped >>>>>> for people to write big things with... I wish the team would address it >>>>>> sooner than later (look at their own c++ code to see the difference). >>>>>> IMHO import conflicts are more often the symptom of bad code than a real >>>>>> issue. >>>>> >>>>> Alas, most languages suffer from poor module systems. A good module >>>>> system should not only allow resolving conflicts between modules and >>>>> making it possible to structure code well, but solve the issue around >>>>> versioned modules so that is is possibly to safely use different versions >>>>> of the same module in the same application. >>>>> >>>>> -Thorsten >>>>> >>>>> >>>>>> >>>>>> Cheers >>>>>>> >>>>>>> -THorsten >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> So be it. But at least there should be no reasons for POP vs OOP wars >>>>>>>>> ;-) >>>>>>>>> (I’d like to add that I liked Dave’s talks at last WWDC very much, >>>>>>>>> it’s just that I don’t think that POP is something new or different.) >>>>>>>> >>>>>>>> I used to thin that way. But today I think that although in broad >>>>>>>> brush strokes the similarities and bigger than the differences, there >>>>>>>> is room for making a bigger difference in the how. >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -Thorsten >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> swift-evolution mailing list >>>>>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution