Re: Silicon Valley D Meetup January 28, 2016
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)
Re: Silicon Valley D Meetup January 28, 2016
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
Re: Silicon Valley D Meetup January 28, 2016
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
Re: Silicon Valley D Meetup January 28, 2016
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 :(
Re: Silicon Valley D Meetup January 28, 2016
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
Re: Silicon Valley D Meetup January 28, 2016
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
