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 <xiaodi.wu@gmail.com> wrote:
On Sun, Dec 25, 2016 at 11:52 PM, Daniel Leping <daniel@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@gmail.com> wrote:
On Sun, Dec 25, 2016 at 11:46 PM, Daniel Leping <daniel@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@gmail.com> wrote:
On Sun, Dec 25, 2016 at 10:50 PM, Daniel Leping <daniel@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
GitHub - blitzagency/amigo-swift: A SQLite ORM for Swift 2.1+ powered by FMDBIn general I think the best showcase is generic factories.
On Mon, 26 Dec 2016 at 9:02 Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Sun, Dec 25, 2016 at 10:18 PM, Daniel Leping <daniel@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@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@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@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@gmail.com> wrote:
On Sun, Dec 25, 2016 at 7:30 PM, Adam Nemecek <adamnemecek@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?