Redundant or conflicting UDF definitions in #included files

[fhammer]

I typically put UDF definitions in "#include" files (#definefunction udfX() ... #endfunction). Some of the UDF's use other (more-generic lower-level UDF's), the definitions of which are contained in other #include files. It would be convenient, to put #include statements for the lower-level, more generic, UDF's at the front of the #include files for the higher-level UDF's.

Eventually, I plan to compile the applications, which may contain nested #includes, resulting in redundant (or possibly-unintentionally-conflicting) UDF definitions.

I understand that #include statements are preprocessor directives, and that they can be nested.

Are redundant #definefunction's ignored?

If so, how is redundancy determined? Function name?

I suspect that redundant UDF definitions would work, but I'm concerned that they might result in a significantly-larger wbt and exe files.

[stanl]

Interesting Questions:  When WB introduced Menus in dialogs I began putting together kind of a garbage-collection drop menu of several independent scripts. At one point the menu script had 27 include files, a majority of which contained a UDF parse() [basically a routine that collected SQL queries and returned a workbook, or template]. I never encountered conflicts, and the exe did not substantially slow down or grow in size, and although I keep telling myself to clean it up.... I commit to the "If it ain't broke, don't fix it" of lazy coding.

Others may have experiences of observations.

[snowsnowsnow]

In answer to the OP:

I believe this is all well-defined in the WB language.  That is, the first definition of a function is the one that matters, and all subsequent definitions are ignored.  This was all discussed at length several years ago.

Personally, I think this is wrong - that it should be possible to re-define a UDF - but some others think differently (some even for actual, substantive reasons - that is, not just cheerleading for the cause).

So, in terms of functionality, you can #include as many definitions as you like - only the first seen will have any effect.  I'd be 98% sure that multiple definitions won't affect runtime speed, though it might have an effect on compile speed and/or code size (neither of which are particularly important metrics).

Finally, note that the only way you can change the definition of a UDF is to drop them all (this is done via some IntControl, 77-something, I think...) and then re-define them all.

[fhammer]

Thanks Stanl and snowsnowsnow. You mentioned that this topic had been discussed al length several years ago. I searched for info, but couldn't find much. I'm not adept at using the Forum. Any ideas about how I could locate the original discussions? Thanks again!!

[stanl]

Finally, note that the only way you can change the definition of a UDF is to drop them all (this is done via some IntControl, 77-something, I think...) and then re-define them all.

I would agree with this 95% of the time, but a tricky use of .wbc files and call() can get around that (for compiled exes). I have used this for situations when an agent or supervisor looks at the same dialog, runs the same udf but with different sets of parameters.

[td]

Thanks Stanl and snowsnowsnow. You mentioned that this topic had been discussed al length several years ago. I searched for info, but couldn't find much. I'm not adept at using the Forum. Any ideas about how I could locate the original discussions? Thanks again!!

I think snow++ has covered all the salient points.  The first UDF/UDS wins and yours script gets bigger and slower as you include more UDF/UDSs.  The latter two points are not of any consequence in most cases because the performance impact is negligible.   I do not recall the discussion snow++ is referring to but it may have been on the  old Webboard that was retired a few years ago.

[snowsnowsnow]

I do not recall the discussion snow++ is referring to but it may have been on the  old Webboard that was retired a few years ago.

Yes.

And note, by the way, that searching/finding old discussions has never really been a strong point (i.e., a stressed feature/functionality) of this forum (although things seem to be better in the new software than in the old).  For better or worse, there seems to be an "out-of-sight/out-of-mind" mentality.

For what it is worth, I think the discussion to which I refer was in the Marty years.  But it was certainly in the old software.  So, it is probably not available in any meaningful sense.  I only mentioned it because I thought maybe some other old-timers like me might remember it.