UDF header syntax - Resolved

[czardas]

I may need to write a second function to call _MyConversionFunc since it is used differently internally. The only difference is that error checks, and variable declarations, are sometimes ignored to increase speed by avoiding duplicated arguments.

; Syntax.........: _MyConversionFunc($vRet [, $aKey = Default [, $bTest = True ]])
; Parameters ....: $vRet  - The number to convert
;                ; $aKey  - Conversion key ... Internal use only
;                ; $bTest - Error checking ... Internal use only

Writing a second function to call the first function with default parameters set seems a bit crazy to me, but if I don't do that I'm not sure how I should describe the syntax? The user only needs to see the following info.

; Syntax.........: _MyConversionFunc($vRet)

Edited November 19, 2011 by czardas

[guinness]

Have a browse through the Wiki entry which Mat has been updating over the last couple of days >> http://www.autoitscript.com/wiki/UDF-spec

About internal functions, you don't have to document what the return codes are etc... as the user shouldn't be accessing these.

[czardas]

It's an excellent article, but I couldn't find any mention of combining internal use only parameters. It's not the return values that concern me. For example the error checks are only performed on the first run when used internally. If the user calls the function, the error checks are performed always. The function is used differently internally than by the user.

Writing a separate function for the user because the header syntax doesn't cater for internal use only parameters just seems like a waste of bytes.

Func _MyUserFunc($vRet)
    Return _MyConversionFunc($vRet)
EndFunc

Edited November 18, 2011 by czardas

[JohnOne]

I think @NumParams could be employed withing the function as a test if you passed them yourself, or they are default.

[czardas]

Good thinking, but it isn't going to work, since sometimes the default values are altered internally and I have no way of knowing whether the function was called by another internal function, or by the user. Also the idea of adding more error checks to see if errors need checking is making my brain ache.

Maybe I should just leave the header syntax the way it is in the first post, and if the user doesn't read the parameter description: too bad! Although it's not entirely correct.

If the user alters the default values when advised not to do so, I'm not responsible.

Edited November 18, 2011 by czardas

[czardas]

It is sometimes the case that I make a U-turn and backtrack on a decision. Since they are not optional, I think that internal use only parameters should be excluded from the Syntax section of the header, so the second example in my first post would appear to be more correct. Information about the excluded parameters can be added to the Remarks section. Voila!

Thanks for the responces.

Edited November 19, 2011 by czardas

[Mat]

The correct way is a new function. When writing a UDF (or for that matter, any code that's going to be read by the community), code correctness is much more important than speed or size. It's not a huge loss: the public function calls the internal function with default parameters.

[czardas]

Thanks Mat. I knew that nudge would get you on the case.

I'll do exactly what you say for a public release, and have a streamlined version for my own purposes. Like you said, someone might include a second or third parameter by accident, making his or her script unstable. Thanks for looking into it.

Edited November 19, 2011 by czardas

[BrewManNH]

I'll do exactly what you say for a public release, and have a streamlined version for my own purposes. Like you said, someone might include a second or third parameter by accident, making his or her script unstable.

If someone is using your function incorrectly, that's their issue, and not something you can prevent. If they send your function too many parameters, they're going to get an error from AutoIt saying "<function name> called with wrong number of args."

[czardas]

I agree with you BrewManNH. Reducing the number of possible errors by considering as many scenarios as possible is the reasoning behind my recent questions. There are many experienced programmers here and your recent responces have made these questions worth while. Hopefully they will have significance to others too.

Thanks