symbol resolution (was:EuCOM : Attn Matt : String Return Value)
CChris wrote:
>
>
> Does the include tree also contain the direct ancestors? If not, there are
> some
> issues with this scheme, which is quite common:
> }}}
<eucode>
-- file1.e
include third.e
global integer n_also_in_third
n_also_in_third=n_init() -- ok, this g.s. shadows anything in third.e
include file2.e
--...
>
-- in file2.e
integer my_var
my_var=n_also_in_third
-- could produec an error, while
-- file1.e::n_also_in_third is obviously being targeted
</eucode>
{{{
> As the name suggests, n_also_in_third is also a global symbol defined in
> third.e.
> I'd consider it a problem if this isn't properly handled.
No, it doesn't climb back up the tree. I can see the logic of it, but I'm
not sure I agree with this. Is it really that common? I know that I've
occasionally been guilty of this.
From the perspective of file2.e, it's not obvious that the correct resolution
should be from file1.e. I think it might be better to give an error in
this case. The resolution would be to include the file explicitly.
Continuing my train of thought from the response to Pete, I guess a legitimate
question to be asked would be whether we should let symbols in directly
included files mask those from lower down in the tree? Assuming, of course,
that no namespace identifier is used, and there is only one possible symbol.
I'm also starting to think that any symbol resolution from beyond the
include tree should generate a warning.
Matt
|
Not Categorized, Please Help
|
|
