"Eric S. Raymond" wrote: > > ... > > > Overloading otherwise undefined special method names for operators is > a well-understood way to add functionality to classes. Lrt's use it. I don't know why you think that this is well-understood. Nevertheless, let's propose we add some fixed list of operators: .+ .* ./ .\ Would you propose that: "abc" .+ "c" => "abc".find( "c") "def" .* ".e." => re.match( "def", ".e." ) " " / ["a","b","c","d","e"] => " ".join( [...] ) "a b c" .\ " " => "a b c d e".split( " " ) To me, these bindings look like the kind of things I'd expect in P3rL, because the relationship between the syntax and the behavior is mostly random. In other words, you can't just invent a bunch of operators and THEN figure out how they are going to be used in various domains. You need to invent the operators *for* the domains. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4