Conceded to Removing Constants from BKJEP’s getSymbols()
Today one of the more annoying developers I work with reported a 'bug' in the BKJEP parser's getSymbols() method - saying that the symbols 'null', 'e', and 'pi' weren't supposed to be there. Well... those are the constants I added a little while back to allow the testing for null as well as the basic math constants. So they are symbols in the JEP sense of the word, but this guy's code wasn't smart enough to realize that not all symbols are those that he supplied.
What I think he's doing is assuming that all symbols are, in fact, tickers to be processed. He then tries to process these tickers, doesn't trap for the possibility that the user entered bad data, and then it bombs because he's done all this optimistic coding and this is just the first place it's been caught.
My first response was to say "Nope. These are symbols and you need to deal with the fact that users might enter bad data as well." But then I got to thinking. Were constants the equivalent of variables?
I had thought BKJEP overrode the getSymbols() method from JEP, but it hadn't. So I really was free to think of this in terms of what they user might really want. When I took the annoying developer out of the mix, and thought about the role of constants in the expression parsing I came to the conclusion that it probably is better to think of them as "invisible" to the variable space. They aren't to be changed... they support the processing, but may take no part in it's execution... in many ways they aren't the same as the other variables returned from getSymbols().
So I filtered them out of the getSymbols() call. I suppose that the better thing to add would be a getConstants() and then maybe a getAllSymbols() or something like that. It you break down the JEP symbols in a way that I thought it was originally, but wasn't: variables, constants, and both.
So, I guess the lesson is try to keep an open mind and even an annoying jerk of a programmer can get something right - even if by accident.