Relative imports.

[back2dos]

When importing things from the same package or subpackage, it would be nice if one could skip spelling out the common path.

package some.long.path.because.we.are.very.serious.programmers;

import some.long.path.because.we.are.very.serious.programmers.ThatOtherThing;
import some.long.path.because.we.are.very.serious.programmers.subpackage.ThatNestedOtherThing;
// instead:
import package.ThatOtherThing;
import package.subpackage.ThatNestedOtherThing;

Also, it I makes it easier to spot the relevant part of the import.

If required, I can make a proposal for this, but I wonder whether it's something we would be willing to have at all. Clearly, this is largely only useful to solve self-induced problems. Unfortunately, the practice that induces them is extremely common.

[Simn]

I had to read that twice before I figured out that you're using package specifically here as part of the import. I think I like this idea, package referring to the package statement makes a lot of sense and doesn't introduce any resolution problems.

[sebthom]

Should this go into haxe evolution?

What if someone actually calls a package "package"?

[kLabz]

Should this go into haxe evolution?

What if someone actually calls a package "package"?

It doesn't parse so it's safe

[sebthom]

Btw. in Python they simply use a . as a prefix which I would prefer over having to use another keyword (package). It is about saving keystrokes after all.

import .ThatNestedOtherThing
import .subpackage.ThatNestedOtherThing

[Simn]

To me it's not about keystrokes but about clarity. And there I greatly prefer the package version.

[back2dos]

Yeah, keystrokes are not the issue. Primarily, I'm looking to avoid redundancy, which the version with package accomplishes just fine.

OTOH I don't see how that extra keyword adds any clarity. It's just noise. Still, without it, the syntax looks like the kind of party trick that Haxe avoids rather consistently.

[Simn]

I really like the term "party trick", and I agree. Something like this would hurt syntactic balance, which is something I care about a lot.

But well, I suppose this really should go through a haxe-evolution in case anyone wants to argue the point further. I don't want to impose my own opinion here.

[back2dos]

Hmm. I guess we're overcomplicating things, but oh well. Next time this bothers me, I'll make the time to formulate a proposal.