I’ll try to explain well what’s my issue here…
I have a project and the sources are in a
src directory. Inside this directory I have a class named
Constant which is without any package since src is included as
Then In my project I use another class, let’s name it
A, from another project which is in a package named
A class I call a field of
Constant class without any package target.
In the package
com I have another class named
So, when I call
A class from my project,
Constant doesn’t target the
Constant class which is without any package but the one that is in
com package (one level lower)
My question is : Is there a way to target the
Constant class (which isn’t in
com package but which is without any package) ?
The solution here is to put
Constant class which is without any package, inside a package, so I will be able to target this one using the specified package.
Another solution would be to use a
typedef inside my projects that targets the project’s
Constant I want…
But I thought I could have a shared
A class with a call to
Constant without specifing any package so it will target the
Constant class which is in the project I’m working on… So this isn’t possible right ?
For me it’s logical since I don’t specify
com.Constant it should call the
Constant class which is without any package (the one related to the project I’m working on…)
F**k, the one who understand my topic is really good…
import Constant as GlobalConstant;
Thanks Aleksandr for your answer, but where should I add this import please ? I don’t understand…
My tree is like that :
In A.hx I have a call like that :
Constant.foo() and it takes not Constant.hx from src but this one from common…
This is another question, and the answer is that this is called shadowing. Aleksandr was answering the question in your OP.
As Aleksandr said, you need
import Constant as GlobalConstant;
You need it in
A.hx (and any other module having the issue), and then replace
Constant.foo() there with
GlobalConstant.foo(). As Kevin said,
com.Constant is shadowing
Constant so you need another way to call
Constant; this is one.
std.Constant.foo() might be another.
Kevin, what is another question ? What are you talking about ?
Thanks for your answer. Ok I understand now.
So, what is called shadowing occurs in the code but not in the import statement right ?
I didn’t understand first the Aleksandr’s answer because I thought if it’s shadowed in the code, doing it in import statement should do the same, but it doesn’t, ok, subtile
Edit: the following was a result of me misreading your folder structure (I misread that Constant is under
common, but actually it is under
common/com). So please feel free to ignore. But still, the content is technically correct just that it doesn’t perfectly fit to your question.
You are asking two questions in this thread, one in the OP and one in my quoted post
First one is related to Type resolving. Given
src/com/Constant.hx and you want to access the root one in
src/com/A.hx, and Aleksandr has answered that.
Second one is about class path shadowing. Given
src2/Constant.hx and you have
-cp src1 -cp src2. In that case the former Constant.hx is shadowed and afaik you have no way to access it anymore.
Ok I see, thanks Kevin.
The second one you are talking about seems logical for me. There is no way to distinguish between the 2 and I would never do something like that.
My issue comes from the first one and yes Aleksandr answered that.
But first time I’ve read the answer I also didn’t understand because I thought if shadowing is ocuring in the code, so it should do the same in the import statement so it will not work neither. But it seems it’s not the case, ok.
In the past I had a similar issue having a local var named the same as a package I used, so I wasn’t able to target a class in this package in the function, that’s also called shadowing If I remeber well but this case was more deductible than this new one.
Good to know,
std. is not preferred unless in macro, where there is no way to generate an import-as-alias statement.
Indeed because imports have to be fully-qualified so
import Constants; cannot mean to import
Import as alias is cleaner and it is a well specified feature.
std. prefix is not really a specified feature afaik, is it more like a hack/workaround.
Yeah, not being a specified feature doesn’t make it really clean.
However, import as alias also has shortcomings in code readability (that can be a little better with good alias naming), and in the fact that a snippet of code in one place can have a different behavior if copy/pasted somewhere else (ok, preventing copy/paste might be a feature xD).
With that said, I also use import as alias rather than