>> IMO HB_FIELDGET() should return NIL if the name >> doesn't exist, just like FIELDGET() returns NIL >> if the field position doesn't exist. Similarly, >> HB_FIELDPUT() should return logical value just >> like FIELDPUT(). > > RTE greatly helps to locate and fix bugs in code.
But it breaks with the behavior of already known functions with similar purpose. I didn't recheck all places, but quick review shows that my code actually relies on this Clipper feature, so adding RTE would require to rethink some lower level functions (IOW it wouldn't be a plugin replacement with better performance), plus it would probably make it useless in some or more places and risky to use it general. >> There is existing FIELDPOS() to find out if a name >> exist. > > But it does not give any compile time field name verification > when -w compiler option is used. Perhaps I lost track here, but none of the solutions we're discussing give a compile-time warning. In fact there isn't compile-time warning even for simple FIELD->NAME access, unless I'm declaring all the field names (which I personally don't do), and even in this case the verification is pretty lose, as the verification is global, not per table. I assume that folks using FIELD*() function know what they are doing, and either explicitly check for error case, or not (for speed) if situation doesn't need it, f.e. when copying common fields from one table to another with different structure. IOW if the goal is to offer a better performing plugin alternative for FIELDGET/PUT( FIELDPOS() ), adding an RTE would just nil this goal. > Small question. > Why such compile time verification is extremely important for > you when we are talking about OOP code and method names but > for field names you prefer code which cannot be verified by > compiler? Probably because database access is usually well isolated in an application and by past experience it's easy to test it well enough to not cause problems in live code. For OOP code, such error cases will be possible _everywhere_ in code and thus would require to create test code which goes through all possible code paths, and redo these tests after each app modifications. Shortly, I had many problems due to mistyped OOP var/method access (most of them in Harbour itself BTW), but very rarely any field name related problem. Of course this is only personal experience and greatly depends on actual usage pattern. Finally I can hardly imagine yet a system that guarantees all or most current freedom in alias/field access usage while giving full coverage for compile-time field name checking. For this, Harbour would require to know the exact structure of all tables at build-time. But, still I cannot see how this is related to HB_FIELDGET()/HB_FIELDPUT() RTE behavior. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
