Monkey C: How to simulate abstract static methods?

the-ninth said:

Is this just a limitation of Monkey C’s type system and static method handling, or is there some workaround I'm missing?

This is how C++, Java, and C# work (where static methods are resolved *statically* - at compile time, not run time), so I'd say it's by design. Whether it's considered a "limitation" might be in the eye of the beholder.

(I realize that what you're asking for is possible in js and python tho.)

the-ninth said:

• Simply calling doSomething() inside A.doMore() just calls A.doSomething().

• Using self.doSomething() doesn't solve it either.

For me, if I write code similar to your example and call doSomething() or self.doSomething() in A.doMore(), I get a symbol not found error at run time (although the type checker is happy, even at the strictest level).

Not sure why we're seeing different behaviour, unless your actual implementation of class C also has a function doSomething(), and it's actually C.doSomething() which is being called.

I would consider the type checker thing a bug tho.

As for the implementation details/reasons behind this, if create an instance of C and call C.doItall(), and you print out the value of `self` (or `this`) in C.doItAll() and A.doMore(), you'll find that it has the same value in both cases (meaning it points to the instance of C in both cases).

If you call A.doMore() from outside of a class instance (like a global function), you will find that trying to print the value of self causes a crash, with a "symbol not found" error.

In other words, `self` only has meaning in the context of a non-static class method, so there's no way for A.doMore() to know that it was invoked as B.doMore().

As for workarounds, you could change your static functions so that they take a "classDef" as an arg (this goes back to the other discussion about whether it's possible to do this "correctly" in the type system, regardless of the fact the Method.initialize() does it.

Whenever you call a static function, you would pass the class itself as the first arg:

import Toybox.Lang;
import Toybox.System;

class A {
    public static function doSomething() as Void {
        System.println("A");
    }
    public static function doMore(staticClass as A) as Void {
        // yes it's bad to type "staticClass" as A, because if
        // A or B is passed in, as intended, the type checker would
        // allow `staticClass.someInstanceMethodOrVariable` to be accessed,
        // which would cause a crash at runtime
        //
        // don't blame me, blame the type checker / language design
        staticClass.doSomething();
    }
    private static function getClass() as A {
        return A;
    }
}

class B extends A {
    function initialize() {
        A.initialize();
    }
    public static function doSomething() as Void {
        System.println("B");
    }
}

class C {
    public function doItAll() as Void {
        B.doMore(B);
    }
}

function test() as Void {
    new C().doItAll(); // prints "B"
}

Specifically, the problem is the type system seemingly doesn't really distinguish between the name of a class (or "classdef") and an instance of said class, for the purpose of variable / arg types.

FlowState said:

Not sure why we're seeing different behaviour, unless your actual implementation of class C also has a function doSomething(), and it's actually C.doSomething() which is being called.

FlowState said:

As for the implementation details/reasons behind this, if create an instance of C and call C.doItall(), and you print out the value of `self` (or `this`) in C.doItAll() and A.doMore(), you'll find that it has the same value in both cases (meaning it points to the instance of C in both cases).

To illustrate what I'm talking about:

import Toybox.Lang;
import Toybox.System;

class A {
    public static function doSomething() as Void {
        System.println("A");
    }
    public static function doMore() as Void {
        // when called from instance of C, calls C.doSomething().
        // when called from global scope or some instance which doesn't
        // have doSomething, crashes with "symbol not found error"
        doSomething(); // [*] line 12
    }
    private static function getClass() as A {
        return A;
    }
}

class B extends A {
    function initialize() {
        A.initialize();
    }
    public static function doSomething() as Void {
        System.println("B");
    }
}

class C {
    public function doItAll() as Void {
        B.doMore();
    }
    public function doSomething() as Void {
        System.println("C");
    }
}

function test() as Void {
    new C().doItAll(); // prints "C" :/
    B.doMore(); // crash at line 12 [*]: "symbol not found error"
}

I don't claim that it's good design that a static function in A can somehow call a function in an instance of C, when an instance of C called A's static function in the first place - even the typechecker agrees with me, as it thinks A.doSomething() is actually being called.

I opened a couple of bug reports for this:

Type checker allows static method to be called without qualifier from other static method in same class, but this fails at runtime with a "symbol not found error"

if instance method of one class calls static method of another class, the 2nd class can inadvertently call instance methods on the 1st class

Thanks for diving into this issue again!

I modified by code for the to take the classdef, but when I call the static method from the classdef (line 15 in your example), I get an "Error: Not Enough Arguments Error". I am running it with SDK 8.1.1.

In my admittedly not-so-great example, only doMore() takes the classdef as an arg, not doSomething(). The example as written should compile and run tho.

If you changed *all* static functions to take the classdef (which would be more consistent), then you would call doSomething() as follows:

staticClass.doSomething(staticClass);

Not sure if this workaround is a good idea tho.

Why do you need methods that are both static and abstract? As mentioned, this is not possible even in java. If you already have an object (i.e you have at least 1 non static method in the class) then maybe it's not that big of an overhead to turn the static method into non-static. Wouldn't that solve all the problems?

FlowState said:

In my admittedly not-so-great example, only doMore() takes the classdef as an arg, not doSomething(). The example as written should compile and run tho.

OK, I need to do some more testing to understand why this isn't working for me.

flocsy🤠 said:

Why do you need methods that are both static and abstract? As mentioned, this is not possible even in java. If you already have an object (i.e you have at least 1 non static method in the class) then maybe it's not that big of an overhead to turn the static method into non-static. Wouldn't that solve all the problems?

I have static logic in an abstract class that is shared across all derived classes. However, it also needs to incorporate static behavior that differs depending on which derived class is calling the abstract class's static logic.

the-ninth said:

behavior that differs depending on which derived class is calling

If it depends on the caller then you'll anyway need to send the caller. Or just use the somewhat strange behaviour of Monkey C that if I understood from this thread and the 2 bug reports kind of does exactly that.

But I'll ask this again:

1. what is the reason to use static methods?

2. am I right in my assumption that if you decided to not use static methods then you wouldn't have these problems? Or maybe I am still missing something.