Hi Nicolas,
as I said earlier, IMHO having to actually use this feature is a code smell.
The question I have is: will this work with interfaces?
Can I say:
interface IFoo {
@:give(foo) function darkFooMagic():Void;
}
class Foo implements IFoo {
@:give(foo) function darkFooMagic():Void;
}
And the compiler enforces that darkFooMagic has at least @:give(foo)
access (but public should also be ok).
Plus, I am wondering how this will be represented at macro-time.
Because having this just somewhere in the meta-data doesn't seem
right, while at the same time I wouldn't want to treat this as an
extra case.
Personally, I think this will overcomplicate things. A lot of people
will be using this instead of just creating a clean type hierarchy.
Accessing something that isn't public is a hack. No matter how pretty
a system you use for it.
As I said, the weird thing about private structures is simply, that
it's not evident and that it kind of overloads the meaning of field
access control (because private usually means "can't touch this" but
suddenly changes its meaning to "can touch this, even if it's actually
forbidden").
I think the solution you are proposing now overshoots the mark and
substitutes a slightly quirky yet weirdly elegant system with a
"dangerously powerful" one. Splitting the choice between public and
private at the declaration site with a arbitrarily distinctive choice
at both declaration and callsite seems like a big deal to me.
It's almost irrelevant how the tags are named. The key questions are:
- Do we need such a system?
- Will this work well with all other language features?
- Isn't such a system promoting poor coding practices?
IMHO allowing something like private(someInstance.privateField) or
$private(someInstance.privateField) or someInstance.$privateField
seems dead simple to me, and good enough. And technically it doesn't
really require new syntax. Nor a complex system that complicates
access control.
--
haXe - an open source web programming language
http://haxe.org
Locked
