Hi,
>> 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
>
> Hi,
>
> I do not use any FIELDGET(), FIELDPUT() on fields that do not exists, so, I
> also like the idea of RTE, that helps find bug more quick. But I'm interested
> in what cases do you use (rely on) the Clippers behavior of "do nothing"
> field access/assignment using:
> FIELDPUT(FIELDPOS("i_do_not_exist"), value)
Two places:
- Transferring records from one table to another,
with overlapping set of fields but different structure.
(to/from temp tables f.e. for quick browsing or editing
sub-tables)
- Upgrading tables to new structure.
And this pretty much sums up all the places where
FIELDGET(FIELDPOS()) dual-calls are made. All of above
is speed critical, especially the second. As far as I
checked quickly the second is safe, the first not
necessarily.
[ Anyway regardless of my actual (or general) usage
patterns, it's IMO bothersome to introduce RTE here,
since it bends the original functions in the same domain
in unexpected way. Or maybe we should form a general
concept as to when to throw RTEs and when not, in
extended (HB_*) core functions. ]
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
