"A defense of so-called anemic domain models" by Luís Marques

  http://www.meetup.com/D-Lang-Silicon-Valley/events/228027468/

We will post a link to live streaming at the time of the meeting: 7pm Pacific time.

Ali

Reminder: This will happen in about 6 hours and 30 minutes.

Ali

On 01/22/2016 03:54 PM, Ali Çehreli wrote:
> "A defense of so-called anemic domain models" by Luís Marques
>
>    http://www.meetup.com/D-Lang-Silicon-Valley/events/228027468/
>
> We will post a link to live streaming at the time of the meeting: 7pm
> Pacific time.
>
> Ali

We are live now:

  https://hangouts.google.com/call/g5ohbh5b6wslyttc5a6qeleumia

Ali

On 01/22/2016 03:54 PM, Ali Çehreli wrote:
> "A defense of so-called anemic domain models" by Luís Marques
>
>    http://www.meetup.com/D-Lang-Silicon-Valley/events/228027468/
>
> We will post a link to live streaming at the time of the meeting: 7pm
> Pacific time.
>
> Ali

I've been listening in on this and the talk about @nogc on constructors highlights the need to me of having more attribute inference. Yes, it works on templates, but not all methods are templates.

int add(int a, int b) { return a+b; }

OK, cool, but what if you want to call that in a @nogc context? Or a nothrow context? Or a @safe context? Won't work!

@safe nothrow @nogc
int add(int a, int b) { return a+b; }

It just gets silly listing it like that. What abotu

import std.conv;
class Foo {
   this(int a) { this.a = a; }
   int a;
}

@nogc void foo() {
   ubyte[__traits(classInstanceSize, Foo)] buffer;
   Foo foo = emplace!Foo(buffer[], 2);
}

That won't work because the ctor is not explicitly marked @nogc!


l.d(9): Error: @nogc function 'l.foo' cannot call non-@nogc function 'std.conv.emplace!(Foo, int).emplace'


Since emplace itself is a template, it isn't the problem... it is Foo's constructor. It isn't a template and isn't marked @nogc, so it won't propagate.



You can fix it by marking `@nogc this(int a) {....}`

But isn't this getting silly? Everything needs half a dozen attributes!



It'd be nice if we could do some kind of implicit cast in the template if the function body is available for inspection. Or something.

In the real world, I rarely see people defensively putting @nogc on functions like this, but that limits down the line :(

On 01/28/2016 08:37 PM, Adam D. Ruppe wrote:
> I've been listening in on this

Why didn't you say hi? :) This has been the first time that we didn't have the attendance list open, so we didn't even know whether others were connected. Come to think of it, I think we were seeing just two connections: Luís and us. Perhaps it was showing just the attendees who had video enabled? Anyway...

> and the talk about @nogc on constructors highlights the need to me
> of having more attribute inference.

Is there a reason why only auto functions have attribute inference? Why not infer all attributes unless they are overridden by explicit attributes?

> Yes, it works on templates, but not all methods are templates.

Agreed.

Ali

On 01/22/2016 03:54 PM, Ali Çehreli wrote:

> "A defense of so-called anemic domain models" by Luís Marques
>
>    http://www.meetup.com/D-Lang-Silicon-Valley/events/228027468/

Luís gave an excellent presentation on anemic domain models (ADM) (Thank you Luís!):

  http://files.meetup.com/18234529/luis_marques_anemic_domain_models.pdf

This presentation made me realize why I've been struggling with clean OOP designs even for very simple programs (e.g. simple games like shut the box, master mind, etc.). I will read more on ADM starting with this one:


https://blog.inf.ed.ac.uk/sapm/2014/02/04/the-anaemic-domain-model-is-no-anti-pattern-its-a-solid-design/

Ali

On Friday, 29 January 2016 at 08:01:54 UTC, Ali Çehreli wrote:
> Why didn't you say hi? :)


There was no chat box!

I'm pretty uncomfortable with the whole video and audio thing. I think I sound terrible and look just as bad. I prefer reading and writing.


> I think we were seeing just two connections: Luís and us.

Yeah, I only saw the two boxes and myself, and I turned my camera + mic off.

> Is there a reason why only auto functions have attribute inference? Why not infer all attributes unless they are overridden by explicit attributes?

The big reason is that for non-template functions, the body isn't necessarily there and it affects mangling.

So if you tried to do the whole .di thing and wrote:

void foo() { ... } // implicitly @safe implementation

and accessed it via

void foo(); // not marked, but no body so cannot be inferred...


You'd get linker errors because the bodyless one now has a different mangled name from being unable to infer.


This can also be relevant with inheritance:


class Base {
   void foo() { a+b; } // implicitly @safe
}

class Derived : Base {
   void foo() { *(cast(void*) 0) = 0; } // totally @system
}


What happens then? Is Derived.foo an error because it cannot override the implicitly @safe interface of Base.foo?

I think: yes, that's exactly what should happen.


But, what if you import an interface file again:

class Base {
   void foo();
}


Can we still make it an error? Eh, not reliably. And then the danger is: here, Base.foo *appears* to be @system, so the compiler will let you override it.

But in the file that uses it, with the full definition, the compiler inferred it to be @safe.


@safe useMyClass(Base base) {
   base.foo(); // allowed, it thinks foo is @safe
}



then the other module, compiled separately via bodyless interface, does:


useMyClass(new Derived());


...and it compiles because Derived *it believes* implements the Base interface correctly.... but now the @safe guarantee was just blown wide open.



With templates, the body must be present at *all* uses, even if compiled separately, so it doesn't fall victim to this, but other functions do bring a few worries.


(though, on the other hand, using a .di file, you could always just lie about the attributes anyway and the compiler trusts you... so maybe we aren't in that great of a position to begin with and this shouldn't be a blocker....)