Re: Feature suggestion: without keyword=
- Posted by CChris <christian.cuvier at ?griculture.go?v.fr> May 20, 2008
- 587 views
Jeremy Cowgar wrote: > > Arthur Crump wrote: > > > > > > without keyword = <comma separated list on one line> > > seems like a good idea. Perhaps restricted to new keywords. > > If Jeremy Cowgar doesn't want to use it, there is no need to. > > > > It's not a matter of if John or Jane will use it, it's a matter of what's best > for the entire community. I think we need some more discussion on this. Any > other thoughts from others? > > Once concern I have is the complexity it may add (I say may because I have not > thought out how it would work) and potential slow down to the parser having > to check if a keyword is allowed in this file or not. > > Chris, can you speak to those two concerns? > This directive is not meant to be used in new code. It is meant to enable code that might otherwise suddenly start breaking to keep going. How it would work is to select which parser switchboard is being used, one that doesn't test (current) and one which does. So * using code without keywords (the default) has no noticeabe effect performance - IncludePush() and IncludePop() push and pop one more item. * using code with keywords= incurs a parsing time penalty (one test for each potential keyword). Execution is not affected. And now that I think about it, it's even simpler to implement this inside the symbol identification routine proper, ie in scanning. No dual parser, just an ifdef and a check when "with keywords" is on and a keyword is identified. While I agree that, for a developer, editing the offending code is not more than 5 seconds of text manipulation, this may not be true for the average user. It's easy to forget using the Whole word only option, and Notepad doesn't have a Search/replace across project option. Upgrading the application is obviously better, but if the maintainer is no longer there or just too busy? Not upgrading the interpreter may be a pain because you'll wind up having several versions and juggle with various paths. Adding a one line directive at the top of a couple files may appear as a lesser nuisance. One last thing: John Doe wrote an app that uses a 3rd party lib which starts breaking. True, he can fix the lib. But this means that he will now distribute a modified version of a lib. Licensing may not be a problem, but what will happen when the author of the 3rd party lib upgrades it any time later, and users will get the new and old versions installed? CChris > The last concern I have is then a division in how Euphoria programmers > program. > I've said many times that consistency in the language is paramount. Starting > to enable/disable parts of the language sounds very dangerous to me. > > To me if you have an application that will only run on Eu 3.1 simply because > of one keyword (continue) then you should either update your application or > continue to run it under 3.1. I do not think we should introduce new parsing > routines and possible/probable? slow downs into 4.0 just so someone does not > have to update a variable name that could easily be done w/a simple > search/replace. > > -- > Jeremy Cowgar > <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>