[Discussion] Confusion of private field access

The Haxe language has a rather confusing article which states that the behaviour of private field access is more or less a protected field accessor, which makes me wonder what the point is of using a private field accessor.

Protected fields are a very rare case scenario, and only ever often used if you want to keep member visibility restricted to internal access via derived classes. For those of you who do not know, a derived class is a class that is extended by another. Taking the example from the article above:

class Base {
  public function new() { }
  private function baseField() { }

class Child1 extends Base {
  private function child1Field() { }

class Child2 extends Base {
  public function child2Field() {
    var child1 = new Child1();
    // Cannot access private field child1Field

The Base class is a derived class from Child1, because Child1 extends it. So by derived class, the variable in Child2's public function called child1 is derived from Base, but you cannot access the private function of Child1 because you can only access protected variables from a derived class.

This is confusing, because there is no mention of the keyword protected even though the private field accessor is considered as such.

What’s more confusing is that if you want to keep certain functions internal because it makes no sense for it to be accessed outside of the scope of the application or library, that the only way to do so would be to make a dummy base class which is then extended by what is otherwise the derived class in any instance.

If you were doing auto-completion in FlashDevelop, the “@:noCompletion” meta-data is a silly workaround to prevent private access fields from being displayed in completion, but does not actually prevent still being able to use that field outside of the intended scope.

Personally, I think Haxe needs to properly implement the protected keyword and have private actually do what it says on the tin, which is to make visibility private, not protected. Is it me, or do the Haxe developer’s not know how visibility works?

There’s always @:access to bypass private anyway.

It doesn’t bother me, for me using and extending a class is very different,
when extending you need access to the internal representation to change the behaviour,
if you just want to add functions to a class there’s the using functionality.

Actually, it’s a class that extends another. “Derived class” means the same thing as “subclass.”

And untyped and Reflect.field(). The “private” keyword is more of a polite request than any real protection.

I once took a class involving OOP in Python, and the teacher explained that there’s no access control at all. But, he went on, “we’re all adults here.” And so we used underscores to indicate “private” variables, and everyone respected each other’s privacy.

A polite request, and maybe a few explanatory comments, should be enough.

Still doesn’t convince me that private is not technically private. Just because you can put in comment - “don’t use this keyword, because you might break something” is more reason to break it than to obey it.

Putting underscores before a variable name is just standard practice for any language to define what is otherwise private variable access, but it’s still initially confusing to a programmer to see private fields being visible in completion.

JavaScript became popular because it was a badly designed language. It’s nice to use purely because it’s simple and just works. Whereas Haxe, on the other hand, while an “okay” language, is trying to redefine the meaning of “private” access. Why? There is no need. If Haxe followed standards, I wouldn’t be here complaining.

It’s especially true when Haxe becomes an employability skill (if it ever becomes that) and employers require Haxe developers (although I don’t see that happening anytime soon). But standards are important, because without standards employers will take one look at Haxe and if they have any clue as to what programming languages do in general, and have a good grasp of conventions and standards in programming, they will turn away.

C# became an employability skill not just because it’s a language developed by a big organisation, but because it followed the standards of C and C++. The same goes for Java, JavaScript and other like languages.

Haxe may get a look in if we see Adobe officially support it in its products, but that is yet to become a reality.

I don’t want to start a flame war just because of this confusion, but I would still like clarification.

Yes, “private” in Haxe means something different than in other languages. Same with “Float,” for that matter. And yes, it would be nice to have something akin to the original meaning of “private.”

But these aren’t big enough flaws to dismiss Haxe itself. If an employer dismisses Haxe after a single glance over a superficial naming issue, that’s their loss.

Don’t forget that haxe is designed to be compiled to other VERY different languages, and any other language has it’s own definition. JS is very dynamic and anything can be added, accessed and changed, while java and c# are the opposite, and actionscript 3 is somewhere in the middle.
Each programmer, witch is migrating from another language, is actually expecting haxe to be similar to his language style.

It’s especially true when Haxe becomes an employability skill (if it ever becomes that) and employers require Haxe developers (although I don’t see that happening anytime soon).

I sure hope that you’re wrong. I really believe in haxe, and the more I learn about it, the more I respect it’s power.
A good programmer, in my opinion, is above syntax. A good programmer can learn the syntax of a chosen language in few weeks, while implementing his knowledge of logical thinking and architectural design.

It’s funny, because just the other day there was a big debate with a haxe user that came from JavaScript and thought that haxe is TOO restrictive :slight_smile:

I don’t believe Haxe is restrictive, I don’t mind using it. But some things can be confusing until you get your head around it. I would still rather call the private field protected instead of private, because that’s the behaviour haxe developer’s are adopting, yet call it private, even though they know it isn’t.

Oh, the irony.

On the other hand, in ActionScript 2, private fields were actually protected. Should all programmers that migrated from ActionScript 2 to ActionScript 3 be confused about the terminology and use of “protected” in AS3?

Haxe was developed before ActionScript 3 was released, there are other simularities with ActionScript 2 (such as package;, not package {}) that are noticeable

I wonder if this might also be related to the fact that Haxe targets different platforms, which may not be able to enforce and unreachable private member at runtime – the current model, hidden but technically still available, probably makes it less complicated. For my own purposes, this model (especially with @:allow) solves the problems I used to solve with private namespaces for engine internal code

In my opinion, that is a frustrating workaround to have to type that over and over for fields that you don’t want accessing outside of your intended scope. In C#, for example (I don’t know how the hxcs library works), you have access modifiers which are: public, private, protected, internal, and sealed (sealed only works on classes). Obviously if you want specific target language functionality, then you might as well just program in that language instead of Haxe, as the Haxe meta-“functions” are an unnecessary bloat and makes code hard to read after a while.

I suppose it just depends on the kind of thing you’re working on, but I can’t imagine trying to create a web server using Haxe having php, java and c# (asp.net) targets. Not only would you need a lot of abstraction and compiler conditionals, but a good understanding of each of those targets so that you can understand how to build your Haxe application.

Now this takes me to a question that is off-topic, but I’m going to ask it anyway… Is the aim of the Haxe language to essentially remove the need to learn so many languages and take away the burden of needing to learn them, or does it have some other aim that I have not heard of yet?

From what I can tell, learning Haxe is easy, but understanding how to build something for a particular target language is difficult to master as you may still require knowledge of that language. The Haxe core API does take away some of the most tedious of tasks, such as IO and XML/JSON parsing, but for things specific to a particular problem - like a web server, or even a GUI abstraction kit for Windows .NET/Mono or Qt - it seems the solution is to know all of those environments and languages to understand how they work.

I was thinking of using threejs and then saw a library for it in Haxe, but considering it’s just an extern and nothing more, I might as well just use JavaScript at that point. OpenFL, which I have used up to this point and will continue to use, I am using because it genuinely takes away a lot of the burden of learning so much, which is why I like using OpenFL.

A lot of Haxe libraries, from what I can tell, are just externs for one target language, which in my opinion is completely useless. I think more libraries like OpenFL need to come out to make things like web development easier, application GUI developer, database server development, etc. That’s where Haxe shines.

Now going back to the topic on-hand, I realise there are ways in which you can force the compiler to say “don’t make this class available to the public, I want it internal”, but that encourages ugly code with insane conditionals.

I wonder how you can organise your code so that the target languages that you intend to build on do not interfere with existing code bases which target other languages that do not support the former. For instance, you can have a code base for a web server that is designed for ecommerce, and you have multiple clients that use different technologies, One PHP, one C#. You can easily compile your codebase into that target language, but then one language doesn’t understand protected and the other doesn’t understand partial classes. The solution? Wrap compiler conditionals around everything until it works, wrap additional accessor methods around those functions that will work in one language but not the other.

I can’t imagine how infuriating that would be.

I agree, I think that the promise of Haxe really shines when you take the time to build a library that (in a reasonable fashion) takes the burden of environmental differences and binds them together. That, I think, is why they have communicated Haxe as a “cross-platform toolkit” – it provides us the tools we need to make OpenFL great, and C++/HTML5/Java/whatever targeting from the same codebase possible :wink:

I think Haxe is consistent in how it handles private, it’s a compile-time, not a runtime feature.