"Joe Earnest" <joeearnestNO@SPAMqwest.netPLEASE> wrote in message
news:OlkJZb6vDHA.1424@tk2msftngp13.phx.gbl...[color=blue]
> Hi Al,
>
> [snipped]
>
> "Al Dunbar [MS-MVP]" <Alan-no-Drub-spam@hotmail.com> wrote in message
> news:OiXCfn5vDHA.3416@tk2msftngp13.phx.gbl...
> | Time to download more up to date docs, Joe. Mine has the following:
>
> The function is documented,[/color]
Ah, you didn't mean "undocumented", but "not FULLY documented".
[color=blue]
> but it's the fact that it circumvents Option
> Explicit[/color]
Not really - see way below...
[color=blue]
> and creates a new variable[/color]
.... as I would expect a DIM statement to do ...
[color=blue]
> instead of erroring out[/color]
.... now *that* would be unexpected...
[color=blue]
> that's
> undocumented[/color]
.... granted. By the same token the "function" and "sub" statements are not
fully documented because they do not define all of the behaviours and side
effects that could result from their use. But I digress...
[color=blue]
> and unintended.[/color]
That's *their* problem. A more important question is: "Is it *expected*" to
which my answer is "Yes". A secondary question is: "will this departure from
a <fixed source> model be completely straightforward", to which my answer is
"obviously not".
[color=blue]
> That's the only reason that it would work for
> the OP in this situation and in the example that I gave.[/color]
.... the reason it works is, well, that is how it works. It doesn't work
because it is a bug, but because the underlying code does what it does. The
fact that this was unintended by the developers is really beside the point.
[color=blue]
> When I first
> stumbled on this behavior over a year ago, Michael Harris verified the
> operation and verified with Eric Lippert (who apparently wrote the execute
> code) that the behavior is both unintended and unlikely to change.[/color]
Unintended: their mistake; unlikely to change: score one for platform
stability.
[color=blue]
>[/color]
http://www.google.com/groups?hl=en&l...961d93f&rnum=1[color=blue]
>
> (from MH post)
>
> "I checked with Eric Lippert (who wrote the Execute and ExecuteGlobal
> implementation code)...
>
> What you observe is actually a bug and unintended behavior.[/color]
I disagree :-) It is only a bug if the behaviour was intended NOT to
happen. Just because they missed a side effect of their own code (especially
one that has some specific uses), they should not go dissing themselves over
their oversight ;-)
[color=blue]
> Execute within
> a procedure is *not* supposed to create a variable with global scope. He
> also noted that this is probably something that will never get fixed[/color]
;-)..."
I consider the related documentation to be in error (or at least misleading)
in this respect, probably because it was written before executeglobal was
implemented. One specific error in the definition of executeglobal is shown
in the extract below, highlighted in ALL CAPS.
I believe the paragraph and disbelieve the endline comments, both because
that makes sense based on what EXECUTEGLOBAL means, and because, well, that
is actually how it works. This also indicates that the writers of the
documentation were, like me, of the opinion that it was *expected* to create
a variable with global scope.
Nevertheless, the Option Explicit documentation states: "When you use the
Option Explicit statement, you must explicitly declare all variables using
the Dim, Private, Public, or ReDim statements. If you attempt to use an
undeclared variable name, an error occurs.". If you execute a DIM statement
with an EXECUTEGLOBAL statement, are you not explicitly declaring the
variable? It is true that this may appear less *explicit* a declaration when
reading through the code, as it could be obfuscated in many ways.
If, as implied, the executeglobal statement was never intended to modify the
global namespace, then what on earth was it supposed to do that execute by
itself could not?
The way I see it is that the developers implemented the Executeglobal
statement to do what it implies (to me at least): execute code as if it was
being executed in the global scope of the script. The fact that it does this
to such a great extent even when that was not their conscious intent speaks
to the quality of their work.
/Al
<extract>
Adding procedures and classes at runtime can be useful, but also introduces
the possibility of OVERWRITING EXISTING GLOBAL VARIABLEs and functions at
runtime. Because this can cause significant programming problems, CARE
SHOULD BE EXERCISED when using the ExecuteGlobal statement. If you DON'T
need access to a variable or function outside of a procedure, USE THE
EXECUTE STATEMENT that will ONLY AFFECT THE NAMESPACE of the calling
function.
The following example illustrates the use of the ExecuteGlobal statement:
Dim X ' Declare X in global scope.
X = "Global" ' Assign global X a value.
Sub Proc1 ' Declare procedure.
Dim X ' Declare X in local scope.
X = "Local" ' Assign local X a value.
' The Execute statement here creates a
' procedure that, when invoked, prints X.
' It print the global X because Proc2
' inherits everything in global scope.
ExecuteGlobal "Sub Proc2: Print X: End Sub"
Print Eval("X") ' Print local X.
Proc2 ' Invoke Proc2 in Global scope resulting
' in "Global" being printed.
End Sub
PROC2 ' THIS LINE CAUSES AN ERROR SINCE
' PROC2 IS UNAVAILABLE OUTSIDE PROC1.
[THIS IS EXACTLY THE OPPOSITE OF WHAT THE FIRST PARAGRAPH SAID. THAT COMMENT
WOULD APPLY HAD THE PROCEDURE USE EXECUTE INSTEAD OF EXECUTEGLOBAL]
Proc1 ' Invoke Proc1.
Execute "Sub Proc2: Print X: End Sub"
Proc2 ' This invocation succeeds because Proc2
' is now available globally.
</extract>
