No package class VS packaged class with the same name

1

Hej,

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 -cp

Then In my project I use another class, let’s name it A, from another project which is in a package named com.project1

In this A class I call a field of Constant class without any package target.

BUT

In the package com I have another class named Constant

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… :rofl:

Thanks

2 
import Constant as GlobalConstant;
3

Thanks Aleksandr for your answer, but where should I add this import please ? I don’t understand…

4

My tree is like that :

  • src
    – Constant.hx
    – Main.hx

and

  • common
    – com
    — Constant.hx
    — project1
    ----- A.hx

In A.hx I have a call like that : Constant.foo() and it takes not Constant.hx from src but this one from common…

5

This is another question, and the answer is that this is called shadowing. Aleksandr was answering the question in your OP.

6

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.

7

Kevin, what is another question ? What are you talking about ?

8

Hi Rudy,

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 :slight_smile:

9

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/Constant.hx and 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 src1/Constant.hx and 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.

10

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,
Thanks !

11

Prefixing with std. is not preferred unless in macro, where there is no way to generate an import-as-alias statement.

12

Indeed because imports have to be fully-qualified so import Constants; cannot mean to import com.Constants.

Why?

13

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.

14

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 std.X.

1 Like