"Andrei Alexandrescu" <seewebsiteforem...@erdani.org> wrote in message news:i3a5d6$pi...@digitalmars.com... > On 08/03/2010 04:31 PM, bearophile wrote: >> BCS: >> >>> The video is up: http://www.youtube.com/watch?v=RlVpPstLPEc >> >> Thank you for the link and thank you to Andrei for the very nice >> talk. I think the link can be put on Reddit too, if not already >> present. When Andrei talks he seems a little different from the >> Andrei that writes in this newsgroup. The talk was quite interactive, >> and the idea of giving away books for good questions was a good one. >> The people in the room seem to know how to program. > > Thanks. I hope the difference is in the "good" direction. Somehow I find > it difficult to grok the right tone on the Usenet. > > Regarding this talk, I was so nervous during it that I was (and am after > watching the recording) unable to assess the talk's quality. I was mostly > on autopilot throughout; for example I seem to vaguely recall at some > point there were some people standing in the back, but I have no idea when > they appeared. >
I thought the talk was great. :) >> 27.50, "transactional file copy": this example was script-like, and >> as short as possible to fit into one single slide, so in this case I >> think using enforce() is OK. But in true programs I suggest all D >> programmers to use DesignByContract with assert() more and to use >> enforce() less. Among other things enforce() kills inlining >> possibilities and inflates code. In D.learn I have seen people use >> enforce() in a situation where DbC is designed for. I think the D >> community needs to learn a bit more DbC, and in my opinion to do this >> the leaders have to lead the way. > > I agree with Walter that enforce() is the only right choice there. > For a slide-presentation I agree. But if I were writing it for myself, I would just use "if()" and "return 1;". (I do like enforce() for other uses though.) >> 42.00: I don't know what Big-O() encapsulation is. I think later you >> explain it a bit more, but I have lost the meaning. > > Sorry. By that I mean an abstraction that uses information hiding to make > complexity an implementation detail, instead of an interface requirement. > Consider e.g. at(int) for a sequence container which makes no claim about > complexity. > I used to disagree with that, but I think I've been sufficiently convinced.