3 ms·
Some of those aren't even dynamic language things. And most of them are bad form. But yeah, shoving a flag onto an object where there was no such flag can come
by qwertyuiop924 10y ago
Some of those aren't even dynamic language things. And most of them are bad form.
But yeah, shoving a flag onto an object where there was no such flag can come in handy at times, if you're treating your objects as dicts or whatever (in JS). If you're doing Real OO, you'd want to put the flag into the class/prototype declaration, so that it's documented, but if you're not, or just need to attach some extra data to, say, a function, it's handy.
Also, in a well documented system, functions should note what types they except, even if it is just "any types that respond to these messages" in smalltalk, or your local equivalent.
- mercurial 10y ago> But yeah, shoving a flag onto an object where there was no such flag can come in handy at times, if you're treating your objects as dicts or whatever (in JS). Ugh, no. I really don't want to be looking at code where properties appear after initialization and you have reason about when the damn thing is actually available, thank you. > Also, in a well documented system, functions should note what types they except, even if it is just "any types that respond to these messages" in smalltalk, or your local equivalent So, like specifying type signatures in Typescript, except probably out of sync because it's not automatically enforced?
- qwertyuiop924 10y agoWell, sometimes, which is why optional type signatures, like those in TS, can be useful. But even if you're not telling all the typing details, at least tell the world that your function works with strings, or whatever. And if you're using the properties everywhere, yeah, define them, but if you need to extend an object, and the extension will only be used locally, than it's useful.