1. Scope of Type and Namespaces
> Larry Gregg writes:
>> An observation on scope.
>> Create a library file with extension .e.
>> Declare a non global type used by a global
>> function in this file.
>> Create a test .ex file which exercises this
>> function by including the file and using
>> the function.
>> I found that if the argument to the function
>> violates the type defined in the .e file,
>> I get an appropriate error, even though the
>> type is not global. Is this by design?
>
> Yes it is.
>
> This applies to more than just types.
> The global function in the .e file can also use local
> variables/procedures/functions that are not
> (directly) accessible outside of the .e file.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
I am sure this applies to constants, too. It would
seem, then, that individual .e files can have local
functions, constants, variables, etc., with the same
names, and still be included in the same program, and
no conflict will result.
I submit this is worthy of consideration in the name
space debate. Apparently, separate name spaces, or
some other mechanism, are maintained for local objects
in individual .e files. This still leaves the problem
of global objects conflicting when including multiple
.e files.
--
-- Larry Gregg
