https://chromiumcodereview.appspot.com/9691040/diff/7013/src/full-codegen.h File src/full-codegen.h (right):
https://chromiumcodereview.appspot.com/9691040/diff/7013/src/full-codegen.h#newcode820 src/full-codegen.h:820: Iterator lookup(Literal* literal) { On 2012/03/14 16:29:03, rossberg wrote:
Nit: Shouldn't this be called 'find' and have the same interface?
In a language with lazy evaluation, yes. In C++ we would need a mechanism to delay the creation of an Accessors instance somehow. Introducing a new abstract class just for this or waiting for lambdas to be available everywhere seems to be too much. :-) In general, I think that mixing lookup and insertion is a bad idea from a design/API point of view. STL has find and insert for this... *sigh* Regarding proper templatization: We discussed this offline, and it was *you* who proposed to do this in a stepwise manner and for pointers only initially. :-) But I fully agree that this class is only a hint that its base class is poorly designed, and we can change this in later CLs. https://chromiumcodereview.appspot.com/9691040/diff/7013/src/hashmap.h File src/hashmap.h (right): https://chromiumcodereview.appspot.com/9691040/diff/7013/src/hashmap.h#newcode301 src/hashmap.h:301: struct value_type { On 2012/03/14 16:29:03, rossberg wrote:
Hm, value_type doesn't seem to fit. I'd call this entry_type, and name
the
fields 'key' and 'value'.
The whole point of this finger exercise was to be more STLish, and value_type/first/second are the names STL uses, so I think I'll leave it as it is. https://chromiumcodereview.appspot.com/9691040/ -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
