fields broken with inheritance #133

New Issue

sb10q · 2021-12-13T19:48:55+08:00

sb10q commented

2021-12-13 19:48:55 +08:00

class A:
    a: int32
    def __init__(self):
        self.a = 42

class B(A):
    def __init__(self):
        A.__init__(self)


def run() -> int32:
    x = A()
    return 0

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "fields `a` of class `B` not fully initialized"', nac3standalone/src/main.rs:224:35

``` class A: a: int32 def __init__(self): self.a = 42 class B(A): def __init__(self): A.__init__(self) def run() -> int32: x = A() return 0 ``` ``` thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "fields `a` of class `B` not fully initialized"', nac3standalone/src/main.rs:224:35 ```

sb10q added the

high-priority

label 2021-12-13 19:48:55 +08:00

ychenfo commented

2021-12-15 03:03:04 +08:00

I think this field initialization check problem is also related to the super (#136) and somehow related to the module type (#40) (should be 'class type' here though).. So maybe we should settle how should this be done, what should be supported and what the semantics should be?

If I understand it correctly, in this case the issue here is more related to the super, if we does not allow arbitrary class methods be called in a static way and only allow the special case of super, things would be more limited, but would probably involve less changes to the type system.

I am not entirely sure... To support arbitrary class methods called in a static method way would definitly be more expressive, but might involve some non-trivial changes to the type system (things like name collision between variable names and class names, type coercion of self..)

I think this field initialization check problem is also related to the `super` (#136) and somehow related to the module type (#40) (should be 'class type' here though).. So maybe we should settle how should this be done, what should be supported and what the semantics should be? If I understand it correctly, in this case the issue here is more related to the `super`, if we does not allow arbitrary class methods be called in a static way and only allow the special case of `super`, things would be more limited, but would probably involve less changes to the type system. I am not entirely sure... To support arbitrary class methods called in a static method way would definitly be more expressive, but might involve some non-trivial changes to the type system (things like name collision between variable names and class names, type coercion of `self`..)

sb10q commented

2021-12-15 11:05:46 +08:00

We don't need to support static methods AFAICT.

pca006132 commented

2021-12-18 16:18:31 +08:00

How is this related to module type? IIRC I said we should get all the fields of parent class to child class for inheritance? (with order preserved) That should fix the problem.

ychenfo commented

2021-12-19 03:12:42 +08:00

How is this related to module type? IIRC I said we should get all the fields of parent class to child class for inheritance? (with order preserved) That should fix the problem.

Ah, yes not closely related, I was just saying that if we want to support calling static method we need to somehow resolve class' name in the type inference, similar to resolve imported modules name.

Yes getting all the fields of parent with order preserved should fix the problem of field init check, it's just about how we decided the way users should call parent's __init__?

> How is this related to module type? IIRC I said we should get all the fields of parent class to child class for inheritance? (with order preserved) That should fix the problem. Ah, yes not closely related, I was just saying that if we want to support calling static method we need to somehow resolve class' name in the type inference, similar to resolve imported modules name. Yes getting all the fields of parent with order preserved should fix the problem of field init check, it's just about how we decided the way users should call parent's `__init__`?

pca006132 commented

2021-12-19 16:27:30 +08:00

Ah, yes not closely related, I was just saying that if we want to support calling static method we need to somehow resolve class' name in the type inference, similar to resolve imported modules name.

Yes getting all the fields of parent with order preserved should fix the problem of field init check, it's just about how we decided the way users should call parent's __init__?

I think we can resolve the class name with symbol resolver?

> Ah, yes not closely related, I was just saying that if we want to support calling static method we need to somehow resolve class' name in the type inference, similar to resolve imported modules name. > > Yes getting all the fields of parent with order preserved should fix the problem of field init check, it's just about how we decided the way users should call parent's `__init__`? I think we can resolve the class name with symbol resolver?

ychenfo was assigned by sb10q

2021-12-21 18:49:17 +08:00

sb10q added this to the Alpha milestone 2022-02-28 10:52:49 +08:00

~~abdul124 referenced this issue 2024-08-19 10:46:33 +08:00~~

core: allow calling parent methods #497

abdul124 referenced a pull request that will close this issue

2024-08-19 15:11:49 +08:00

core: allow calling parent methods #497

sb10q closed this issue

2024-08-26 18:37:56 +08:00

Sign in to join this conversation.