On 06/17/12 18:38, Andrei Alexandrescu wrote: > > This is a good idea because the traits are useful within and outside the > algorithms discussed in EoP. > > However, I don't think we need to abide strictly to the nomenclature > (e.g. some of the stuff in EoP was already defined with a different > name) although some EoP names are more mathematicky (such as "Codomain" > vs. "ReturnType"). One issue is when EoP goes off and defines its own > terms such as "regular type", which is usually known as "value type". In > fact, "regular type" means something completely different in PL > research. EoP's terminology didn't catch up outside C++ and sometimes > outside a small group within it. > > If I'm allowed to venture an opinion on EoP itself, it's an interesting > book but I don't find it as big or great as some of its fans believe. > It's not breaking any new ground, instead it explores more along already > well-trodden territory, and it fails to find new mother lodes. Some > (many?) chapters (such as transformations and orbits) describe some > self-important notions but fail to demonstrate their general > applicability. Nevertheless, the code really is exquisitely written, and > studying it has significantly changed my approach and style in > implementing algorithms. > > > Andrei
What would you recommend ? Something more practical as Stroustrup and Sutton N3351's proposal : http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3351.pdf We can also get inspired by Sutton's origin project : http://code.google.com/p/origin
