I believe you're confusing in-class factory methods with factory pattern. Factories can be separate objects and it's a very different situation.
On Mon, 26 Dec 2016 at 11:46 Xiaodi Wu <[email protected]> wrote: > On Mon, Dec 26, 2016 at 1:10 AM, Daniel Leping <[email protected]> > wrote: > > I'm giving a wider range, which is about ANY factory pattern related > stuff. Doesn't look to be narrow to me. > > > I thought factory methods were regarded as undesirable in Swift? One of > the stated reasons for failable initializers was: "Failable initializers > eliminate the most common reason for factory methods in Swift... Using the > failable initializer allows greater use of Swift’s uniform construction > syntax, which simplifies the language by eliminating the confusion and > duplication between initializers and factory methods." < > https://developer.apple.com/swift/blog/?id=17> > > > On Mon, 26 Dec 2016 at 11:38 Xiaodi Wu <[email protected]> wrote: > > On Mon, Dec 26, 2016 at 12:58 AM, Daniel Leping <[email protected]> > wrote: > > Well, reflection is a huge performance drop. Protocol conformance is way > better. > > > I'm not sure how huge it would be in the grand scheme of things; in your > example, you are still evaluating a train of protocol conformances and > casting at runtime. Of course, compiler magic can be fast, but I still > don't see how this is a "very common use case" (as you write) that would > justify magic equivalent to that for Objective-C bridging, which is what > you're saying it should be. If `DefaultConstructible` is useful only when > it's magic and the specific use case is dependency injection/inversion of > control, then we're getting very specialized here. > > > On Mon, 26 Dec 2016 at 11:26 Xiaodi Wu <[email protected]> wrote: > > On Mon, Dec 26, 2016 at 12:50 AM, Daniel Leping <[email protected]> > wrote: > > I'm not arguing for implicit conformance in general, but I'm telling that > DefaultConstructable is the same basic level as AnyObject, which is > conformed implicitly. > > Shortly, I'm against implicit conformance in general. I'm positive with > "automatic compiler magic" conformance to DefaultConstructable for any > object having a default constructor as it really is a very basic stuff. > Otherwise you will have to add explicit conformance to it in almost every > class of yours (annoying). > > > Well, this sounds very different from Adam's proposal, where he proposes > semantic meaning for `init()` that, as he described, means that it cannot > apply to every type that implements `init()`. However, he also just said > that he thinks that all types with `init()` should conform, so I guess I'm > confused which way that is. > > At base, you want a way of knowing if a type has `init()`. That sounds > like reflection to me, not protocol conformance. For the record, I look > forward to the day when AnyObject magic is removed; I assume it is coming > eventually. > > > On Mon, 26 Dec 2016 at 11:14 Xiaodi Wu <[email protected]> wrote: > > On Mon, Dec 26, 2016 at 12:43 AM, Daniel Leping via swift-evolution < > [email protected]> wrote: > > Thank you, Adam! > > > Wait, are you arguing for implicit conformance or not? > > On Mon, 26 Dec 2016 at 11:12 Adam Nemecek via swift-evolution < > [email protected]> wrote: > > > Swift doesn't do implicit conformance. It always has to be declared > explicitly. I'm pretty sure Doug Gregor can explain why better than I > could. > > > I don't think Daniel was arguing for implicit conformance, he's saying > that if it makes sense for an object to have a default constructor, it > makes sense for it to conform to the protocol which I agree with 100%. > > On Sun, Dec 25, 2016 at 9:17 PM, Dave Abrahams via swift-evolution < > [email protected]> wrote: > > > > > on Sun Dec 25 2016, Daniel Leping <[email protected]> wrote: > > > > > > > You are right, usually it's required to implement a protocol which is > not a > > > > good approach. The best is plain objects which can be used independently > of > > > > ORM if needed (as DTOs, i.e.). > > > > > > > > I was thinking of DefaultConstructable as a protocol automatically > applied > > > > to any class/struct having a default init, which is really logical for > > > > me. > > > > > > Swift doesn't do implicit conformance. It always has to be declared > > > explicitly. I'm pretty sure Doug Gregor can explain why better than I > > > could. > > > > > > > On Mon, 26 Dec 2016 at 9:41 Xiaodi Wu <[email protected]> wrote: > > > > > > > >> On Sun, Dec 25, 2016 at 10:50 PM, Daniel Leping > > > >> <[email protected]> > > > >> wrote: > > > >> > > > >> Ok, an example from ORM. You have an entity factory with a virtual > (read, > > > >> overloadable in the subclasses) method populating the properties. > > > >> DefaultConstructable is a great choice here. Otherwise you will have to > > > >> force the users of your ORM to implement a certain protocol, which you > most > > > >> probably would like to avoid. > > > >> > > > >> > > > >> Sorry--I'm not very familiar with using Swift for ORM purposes. Why do > you > > > >> want to avoid having your users conform to a certain protocol? Wouldn't > the > > > >> users of your ORM have to conform to `DefaultConstructible` then? I'm > > > >> looking at Swift ORMs, and all require users to conform to a protocol or > > > >> inherit from a base class, typically named `Model` or similar. From a > quick > > > >> Google search: > > > >> > > > >> https://vapor.github.io/documentation/fluent/model.html > > > >> https://github.com/blitzagency/amigo-swift > > > >> > > > >> > > > >> In general I think the best showcase is generic factories. > > > >> > > > >> On Mon, 26 Dec 2016 at 9:02 Xiaodi Wu <[email protected]> wrote: > > > >> > > > >> On Sun, Dec 25, 2016 at 10:18 PM, Daniel Leping > > > >> <[email protected]> > > > >> wrote: > > > >> > > > >> Usually it's a generic function that needs to return a value from some > > > >> other function or a default value (zero) in a case of some conditions. > > > >> Optional value is an arguable solution in quite some scenarios. Afaik, > > > >> sometimes it can be used for optional resolution. > > > >> > > > >> > > > >> Right, I'd agree that Optional is the idiomatic way to do it. Afaict, > > > >> there's not much you can do with a default value that you couldn't with > > > >> nil, unless you have some guarantee as to _what_ that default is; > however, > > > >> I'd expect that in every case that you can rely on a guarantee about a > > > >> default value which would be more useful than nil, it's going to require > > > >> more specific knowledge of your type than an all-encompassing > > > >> `DefaultConstructible` can provide. > > > >> > > > >> Also, generic factories. Widely used in ORM solutions. > > > >> > > > >> > > > >> Can you elaborate on this? Why is Optional not a solution here? > > > >> > > > >> > > > >> As mentioned above, algorythmical stuff that requires Zero. > > > >> > > > >> > > > >> I'm still not convinced there exist credible use cases that need to be > > > >> generic over both collections and floating point, for instance. In > fact, in > > > >> my experience, there are few math-heavy algorithms where one can ignore > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
