Greg Ewing wrote: >>For Numeric/Numarray, I think and1/or1 would be unnecessary. If that >>were true in general it would simplify the proposal signifigantly: >>and2/or2 could be renamed to and/or and and1/or1 could be dropped. > > > It's true that none of the use cases I put forward need and1/or1. But > I was trying to think of the future and at least show how the general > case could be accommodated. > > Leaving out and1/or1 would make things simpler, but at the risk of > someone coming up with a use case for them in the future, requiring > yet another change. Wouldn't it be best to get things right from the > beginning if possible? Sure, assuming using and1/or1 is the right approach. I'm not convinced it is. I think it would be better to start with something simple, but design the syntax so that it can be gracefully upgraded if compelling use cases emerge. My first thought on seeing the current proposal was that the special method names need changing. and2/or2 should be just and/or since these are the methods that will actually be used. I don't have a good name for and1/or1, but it's probably not hard to be more descriptive than the current names. Some imperfect possibilities: shortcircand, scand, preand, andsc. scand is my favorite of these. I suppose and1 could even be kept and only and2 renamed. After renaming stuff, we're halfway to the simpler solution. The next step is, having established both that it's possible to implement full, custom short circuiting as per your patch and that there are no use cases for the custom short circuiting yet, we then just drop scand/scor until a compelling use case shows up, if it ever does. > Also, the simplification wouldn't be all that great. There would > still be the need for two bytecodes per boolean operation to > accommodate either short-circuiting or not. All that would be saved is > testing for and calling the and1/or1 methods. I'll take your word for it that the implementation would not be appreciably simpler. However, conceptually it's much simpler without __and1__/__or1__. Explaining the full version looks difficult, so why burden ourselves with that if we don't have to. At least not yet. -tim
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