This is a very old discussion that took plays years ago with POJO vs JavaBean approach. For sure, extensions give us a bit more flexibility, though the subject remains the same.
Extensions are not a panacea and I think we should always look back for good proven patterns rather than reinvent the wheel. Also, consider SpringFramework-like solution in Swift. How would you deal with object factories without DefaultConstructable in an elegant way? Also, I have some plans to work on one soon, so I consider this topic quite some important. On Mon, 26 Dec 2016 at 10:25 Xiaodi Wu <[email protected]> wrote: > On Sun, Dec 25, 2016 at 11:52 PM, Daniel Leping <[email protected]> > wrote: > > Ok, which approach is easier? Plain struct working out of the box or > adding an additional conformance? I like the usage be as easy as possible > and as less effort as possible. > > > I'd say `class Foo { ... }` and `class Foo : Model { ... }` are equal in > ease and effort. > > On Mon, 26 Dec 2016 at 10:20 Xiaodi Wu <[email protected]> wrote: > > On Sun, Dec 25, 2016 at 11:46 PM, Daniel Leping <[email protected]> > wrote: > > You are right, usually it's required to implement a protocol which is not > a good approach. > > > Why is it not? > > > The best is plain objects which can be used independently of ORM if needed > (as DTOs, i.e.). > > > An object that conforms to some protocol can still be used independently > of the ORM solution! > > I was thinking of DefaultConstructable as a protocol automatically applied > to any class/struct having a default init, which is really logical for me. > > > > 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 > even the distinction between integers and binary floating point. By the > time you get down to matrix math, you start to run into difficulties that > require separate implementations for Float and Double. > > On Mon, 26 Dec 2016 at 8:38 Xiaodi Wu <[email protected]> wrote: > > Can you give some examples of what you used this approach to do? > > > On Sun, Dec 25, 2016 at 9:49 PM, Daniel Leping <[email protected]> > wrote: > > +1 to this approach. I remember I had to create it on my own for my > projects. Would be nice to have it out of the box. > > On Mon, 26 Dec 2016 at 8:11 Adam Nemecek via swift-evolution < > [email protected]> wrote: > > > Yes, those particular types have initializers that take no arguments. > That does not address my question. You merely restated your initial > observation that many types in Swift have implemented `init()`. > > Right, it's an empirical argument. > > > I didn't think the value returned by `init()` was regarded as any sort > of zero--or even any sort of "default." In fact, some types in Foundation > have a static property called `default` distinct from `init()`. > > Let's not talk about those then. This would not apply to every single type > in existence, as I've stated previously. > > > It gives you something different every time. How can this be squared > with your stated motivation regarding concepts of zero and concepts of > equality? > > Due to the fact that it's a resource, not a value. As I've stated above, > not all of this applies to types that are more resource-like. > > > Or, it's what you get because that's the most trivial possible string. > Quite simply, I do not think the designer of most types that implement > `init()` have paused to wonder whether the value that you get is the > identity element associated with the most useful and prominent operation > that can be performed on that type. I certainly never have. > > This is an appeal to tradition. > > > The statement I wrote was in JavaScript, so I'm not sure what you mean > by returning an optional. `[].reduce((a, b) => a + b)` results in an > error in JavaScript. In Swift, such a function may also be implemented with > a precondition that the array is not empty and would not return an optional. > > I was talking about their analogous swift implementations. > > > Can you give an example of an algorithm dealing with tensors where you > would use a `DefaultConstructible` generic over all types that have > `init()`, as opposed to working with the existing `Integer`, > `FloatingPoint`, and other numerical protocols? > > If it's implemented as either nested collections or numbers. > > > > On Sun, Dec 25, 2016 at 6:00 PM, Xiaodi Wu <[email protected]> wrote: > > On Sun, Dec 25, 2016 at 7:30 PM, Adam Nemecek <[email protected]> > wrote: > > > Is it well settled, either in Swift or in C++/Rust/etc., that the value > returned by a default initializer/constructor is regarded as an identity > element or zero? > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
