[swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

[Xiaodi Wu]

On Mon, Dec 26, 2016 at 12:05 AM, Daniel Leping <daniel at crossroadlabs.xyz>
wrote:

> 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?
>

Without being extremely familiar with this area, I'd imagine it would
depend on more advanced reflection facilities in any case, which are a
topic for future versions of Swift. Moreover, in a language where immutable
value types are idiomatic, `init()` wouldn't help you there at all, and
you'll have to be working with code written in a very different way anyway.
So I guess I'm not sure why conforming to a protocol explicitly (and
retroactively, if necessary) is what's standing in the way of whatever
solution you're reaching for.


> 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 <xiaodi.wu at gmail.com> wrote:
>
>> On Sun, Dec 25, 2016 at 11:52 PM, Daniel Leping <daniel at crossroadlabs.xyz
>> > 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 <xiaodi.wu at gmail.com> wrote:
>>
>> On Sun, Dec 25, 2016 at 11:46 PM, Daniel Leping <daniel at crossroadlabs.xyz
>> > 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 <xiaodi.wu at gmail.com> wrote:
>>
>> On Sun, Dec 25, 2016 at 10:50 PM, Daniel Leping <daniel at crossroadlabs.xyz
>> > 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 <xiaodi.wu at gmail.com> wrote:
>>
>> On Sun, Dec 25, 2016 at 10:18 PM, Daniel Leping <daniel at crossroadlabs.xyz
>> > 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 <xiaodi.wu at gmail.com> 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 <daniel at crossroadlabs.xyz>
>> 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 <
>> swift-evolution at swift.org> 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 <xiaodi.wu at gmail.com> wrote:
>>
>> On Sun, Dec 25, 2016 at 7:30 PM, Adam Nemecek <adamnemecek at gmail.com>
>> 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?
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161226/ea694634/attachment-0001.html>