On 3/16/15 2:21 AM, Stanislav Malyshev wrote:
> > if ($zebra in $zoo) {}
> Two things here:
>
> 1. If you're looking whether your zoo has a zebra, and you're doing it
> by inspecting every inch of your zoo and checking if it doesn't contain
> a zebra by any chance, you're running your zoo wrong. I hope this
> metaphor is clear :)Heh heh. True. However the flip side is that this ends up being a rather common practice (for good or bad). Stuff like "Is this state in my array of all states" or "Is this country in my array of all countries" ends up happening a lot. I like (personally) having this simplified syntactic sugar on this. > 2. We don't talk to computers in natural language. For many reasons. So > part of the cognitive process of any programmer is translating his > thoughts into patterns that particular software (we rarely talk to > hardware directly anymore) understands. From that POV, it doesn't matter > too much how exactly bytes that you use to represent it are arranged, as > long as they are not unnecessarily unwieldy. That, of course, is a > matter of opinion, and my opinion is in_array is fine in that regard. Totally understood. Though my argument wasn't about bytes. But just 'simplified brain to code'. Since one could start arguing that we start coding in whitespace instead :) (ok ok, that was a joke). But yeah. I get your POV on that. My own brain just looks at the in syntax and goes: "oooh, that's what I wish it had been from the beginning" >> And the newer people to the language often get tripped up on exactly >> these kinds of things. Lowering that cognitive barrier to translating >> one's thought, to code. I feel is going to be a benefit here. > Frankly, I don't see how that would help. Because with this operator, > you'd have to tell them: > > 1. It's the same as in_array function, it goes through array and checks > if the element is there. > 2. But not exactly - in_array can do non-strict lookup, this one can't. > 3. Oh, but instead it also works on strings. > 4. Where it is like strstr except it doesn't tell you *where* the > substring is. > 5. And if you want to use it like Python's "in" you shouldn't because > Python's works on keys while ours works on values. > 6. And unlike many other languages you can't use it in a loop either. > 7. And if you want to write an *efficient* lookup you shouldn't use this > operator at all. > > I don't think it is a cognitive simplification. Yeah - those are good points. Though I'd see this from the POV of step-by-step knowledge transfer. You wouldn't teach "look at all these complications". You'd be able to give the '1st day lesson' on "How to see if something is in an array" ... and "How to see if a string is in another string". And showing them this simpler cognitive version. But then you start going deeper on 'advanced stuff' later :) (and yes, in_array becomes 'advanced stuff' at that point. It's too bad that there isn't a way to do an operator like this, in such a way that it's more efficient and/or allows for non-strict like in_array. Thanks for the input Stas ... I'll keep mulling this over and seeing what others say here as well. Eli -- | Eli White | http://eliw.com/ | Twitter: EliW |
signature.asc
Description: OpenPGP digital signature
