Implementation of the "private" keyword

Hi!

In the docs it says "The private modifier specifies that the member can only be accessed in its own class."

To me it seems that private (and protected aswelll for that matter) members are only accessable in the same OBJECT rather than the same class.

class A {
    private var _member;
    
    public function initialize(){
        
    }
    
    public function calcMember(){
        _member = doSomeFancyCalculation();
    }
    
    public static function createFromStorage() as A {
        var newA = new A();
        
        // Error: Symbol Not Found Error
        // Details: Could not find symbol '_member'
        newA._member = Storage.getValue("key_storedMember");
        
        return newA;
    }

}

Am I missing something?
This is weird, right?

It makes something like a static factory method very cumbersome to implement.

Let me know if I've missed something here. If not, I think the docs should be updated and this restriction (compared to e.g. java) should be mentioned.

Top Replies

All Replies

  • Because C++ was always a joke of a language?  It was never really OOPS since day 1!

    Fair. I picked C++ because it's the oldest out of C++, C# and Java, as I realize that some people don't like things that are too new.

    Is there a good reason that Java and C# also have the same semantics? I guess they're jokes too.

    https://stackoverflow.com/questions/1631124/accessing-private-member-of-a-parameter-within-a-static-method

    https://softwareengineering.stackexchange.com/questions/246633/why-is-a-private-member-accessible-in-a-static-method

    Someone also mentioned that PHP works that way.

    Do you have an example of a popular language that has similar semantics (private/public and static/non-static) but doesn't work this way? (I'm not saying none exist, but I can't think of any right now.)

    Can you explain why the documentation says:

    "The private modifier specifies that the member can only be accessed in its own class."

    Again, regardless of what other languages do or what we expect Monkey C to do, the documentation should be accurate. The documentation describes behavior just like that joke of a language C++, C# and Java, but the behavior is different.

    but practically there should be no difference between static class function and global function

    I could go further and say in that case we don't need static class functions either.

  • could go further and say in that case we don't need static class functions either.

    Yes Slight smile It is enough that I can do something one way and removing PRIVATE solve problem.

    And the most important thing with PRIVATE is to protect it from outside so Monkey C do it very well.

    Quote

    Again, regardless of what other languages do or what we expect Monkey C to do

    Again yes Slight smile

    I suggest: They are not considered class's static functions.

  • in that case: what would be the point of static functions?

  • Yes, you are right, standardisation should be kept (if we decide that standard is c++/java) and you can make bug report and wait or you can write app bypassing it. For me this implementation is logical and even in java/c++ it's possible I would never have had the idea to hide a member and then try to change it in a static function.

    BTW, in case of Garmin's app  there are a lot of problems to solve and if you hit the wall with limit of memory (e.g. 92kB for WF) you will remove all redundant code like static function. Slight smile I had beautiful code with multidimensional arrays - 360 bytes, split it to three one dimensional, code is ugly now, but save 240 bytes...

  • Sure, I would go further and say that to really save memory in Monkey C (like for a 16 to 32 KB data field), you should avoid using classes, dictionaries, switch statements, enums, etc., except where necessary to use Garmin’s API. You can also bitpack your arrays, hardcode your constants, etc.

    For example, for one data field, instead of using a class to implement a queue or stack, I use global functions where the first argument is the “this” object (which is actually an array returned by an initializer function.) It’s incredibly ugly but saves so much memory, since there’s a huge amount of overhead for classes in Monkey C, compared to the amount of available memory.

    Instead of using a custom exception handler to catch errors (this wastes memory again bc classes), I use a global variable and check it at the appropriate time.

    Having said all of that, I still want Monkey C’s features to work as documented, even if I personally won’t use all of the features in every single case. 

    I don’t really think it’s an answer to say “this feature wastes memory so it doesn’t matter if it’s broken”, since almost everything in Monkey C wastes memory.

    For me this implementation is logical and even in java/c++ it's possible I would never have had the idea to hide a member and then try to change it in a static function.

    As OP pointed out, one use case is the Static Factory Method pattern. Another somewhat related pattern would be the Singleton pattern.