Deprecating the "Sub...End Sub" construct.

[na5m]

Code Block II seems to work just as well as Code Block I. So why not deprecate the use of the "Sub...End Sub" construct in favor of "Function...End Function"? Functions seem to be superior to subs. They can do everthing that a Sub can do in addition to returning a value (and functions don't even have to return a value, if you don't want them to). So why not simplify life and use only functions (in VBScript, anyway)? Any thoughts?

'Begin Code Block I
Sub cmdButton1_onClick()
 Alert "4 ^ 3 = " & CubeIt(4)
End Sub
'End Code Block I

'Begin Code Block II
Function cmdButton2_onClick()
 Alert "5 ^ 3 = " & CubeIt(5)
End Function
'End Code Block II

Function CubeIt(x)
 CubeIt = x ^ 3
End Function

"The poor and the needy - are selfish and greedy"
Morrissey​

 

[dilettante]

The presence of the multi-statement Function was a very useful introduction to VBScript and other languages derived from Basic when it was introduced. Multi-statement Subs in one form or another have been there since nearly the beginning.

While it is true that one can call a Function as one would a Sub (implicitly instructing the language processor - interpreter or compiler to discard the returned result) the whole point of a "function" in the first place is to perform an operation within an expression and leave a calculated result in its place. Using a function as a Sub is both crude and rude... though we do it all the time when we don't need the result. ;-)

Declaring a Sub vs. a Function when there is no returned result is also a form of communication to the programmer who follows behind you reading your code. It makes the positive statement that this subprogram is meant to perform an action, not calculate a result.

It also provides the equivalent of a "void" typed function in strongly-typed languages such as C. There are places where you can pass a function pointer to a VBScript Sub where a function pointer to a JScript function will fail - but these are rare. Most COM objects that script can invoke have jiggered around this so a JScripter can call them too, and non-ACtiveX DLL calls are not supported in these scripting languages. So I agree that this is a weak point.

One might as well ask "why not deprecate comments" or "why bother using proper mixed case on VBScript keywords" or "why bother breaking up lengthy statements with line-continuations?" Or in general promote other practices of sloppy and discourteous scripters that "work well enough?"

I find it tremendously annoying to see Functions defined that make no attempt to return a result. It can be a waste of time trying to scope out what a lengthy function does, only to determine it isn't a function at all, but instead a Sub clumsily coded as a function.

I am truly amazed this has come up twice recently here. Is it really such a big deal to just use VBScript as it was designed? There is probably a long list of more important improvements that could be made.

Just my 2 cents.

BTW - I think VBScript is pretty stable at version 5.6 and I don't expect to see many (if any) future updates. The new .Net "scripting" will probably replace it - several 3rd party hosts have been released already and it is only a matter of time before IE supports .Net languages too.

 

[mrmovie]

sounded more like a fist full of dollars!!!
;-)

where is the .net scripting forum on this site??

regards,
von moyla

ps i will make sure that my posts use line breaks in the future, though i do think i am good with the mixed case key words!!! ha ha

i cant stand line break characters, they confuse me rather

 

[na5m]

So dilettante, according to you I should more or less do the following: When I need a procedure and need it to return a value, I should use a Function. When I need a procedure and don't need it to return a value, I should use a Sub? If this is what scripters (and programmers) do, then I want to do the same. Lemme know. Thanks for responding! na5m.

"The poor and the needy - are selfish and greedy"
Morrissey​

 

[dilettante]

na5m: Well in VBScript that's where you'd make your choice: "Does this thing need to return a value or not?"

In things like event handlers, sometimes a return value is sent back though the Function value, other times it is sent back though a property on the window.event object and you use a Sub.

VBScript isn't perfect. It just is and I've learned to try to go with the flow. I hate the ugly continuation break convention in VB/VBA/VBScript myself mrmovie but it beats having 200-character lines for some statements.

Personally I prefer the semicolon line-separator as is used in JScript and other stuff descended from C (which in turned ripped it off imperfectly from Algol). Of course I'm no C fan - but I still write it. When in Rome, wear a toga.

I'm amazed nobody has released a "PascalScript" or "ModulaScript" engine compatible with WSH and ASP (maybe even IE) yet. Myabe they have and I missed it?