`methodcaller` (https://github.com/python/cpython/blob/6a6bcf16370beff2e0d1a...) is just syntax sugar around `getattr` + a function call which is just syntax sugar + default implementation of `__getattr__` which is basically exactly what it looks like your lua example is (I'm not that familiar with lua).

Actually, I didn't even know about `methodcaller` till I read this blogpost, so I would have implemented your example in python as: `getattr(table, string)(...)`.

Except now you can't have advanced methods on your container types without intermingling the keys of methods and data.

This is why javascript moved away from their "super user-friendly" concept of objects-as-maps towards having a real `Map` type - because mixing data and program can get weird (and if it's user-controllable data, dangerous).

I suppose the question is - is it possible for a table in lua to contain separate entries for the string "foo" and the symbol "foo", or will one happily overwrite the other?

In Lua terms, the question doesn't even make sense. Symbols are just strings which you can type without quote marks using the . accessor, table.foo is syntax sugar for table["foo"].

I have no idea what you mean by advanced methods on container types though. I find the simplicity of Lua tables liberating rather than constraining.

Lua tables are a Map type, anything except nil can be a key, and every key has a value: if you haven't assigned something to that value, it's nil. There's no separate "object" and no separate "symbol", those patterns are implemented using tables and strings. Even global environments (you can have as many as you need) are just tables.

By "advanced methods" I mean, for instance, python's `.update(other)` method (which allows you to merge two dicts/maps), or `.pop(key)` (which allows you to remove & return a value at the same time).

Having such methods on a table which you're still expecting to use as a container sounds like it would allow a attacker to e.g. overwrite your methods if you're processing user-controllable data.

I'm not sure I've observed a lot of folks in the JavaScript world using Map. I agree there are occasions when it's very useful, but for my money those have more to do with cases where you need non-string keys. For everything else, as far as I can tell, Objects remain entirely idiomatic despite their idiosyncrasies.

That's interesting - I must have just been lucky in what I've encountered ES-wise as of late. It relieved me greatly to no longer have the horror of mixing user data and method/"special" names.

I love

  { __proto__: null, foo: 'bar' }

That creates a clean prototype-less map/record object. I always wish they would add special literals to create such objects.

oh, this is fascinating. I might have to add this to my bag of tricks.

I thought the main reason for `Map` was mainly for non-string keys?