Type origin isn't respected for property access

[Stan Lagun]

Due to the versioning issues if class Y is inherited from class X and Z is inherited from Y it doesn't necessary mean that Z is inherited from X. It fact it might be X' - different version of the X as long as it meets Y's requirements. This happens in very complex inheritance case of multiple inheritance when several versions of the same class encounter within parents graph.

The implication is that in order to traverse all the type parents one need to know type origin - the root of inheritance graph which has the information that X' should be used instead of X.

Most of MuranoType method that require inheritance graph traversal use receiver (self) as an origin. The only case when it is incorrect is when operation is done on upcasted object ($obj.cast(ParentClass)).
There are at least two cases when type origin is not respected:
1) $obj.cast(Parent).method() - in order to invoke method() a context with all methods starting from upcasted type is built. Thus origin is going to be the Parent class instead of type($obj)
2) Property modifications. Property access involves property lookup and thus inheritance graph traversals. But internally some of them are done on upcasted object type. Also it is possible to set the property of upcasted object in MuranoPL

[OpenStack Infra (hudson-openstack)]

Change abandoned by Stan Lagun (<email address hidden>) on branch: master
Review: https://review.openstack.org/349158

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/349813
Committed: https://git.openstack.org/cgit/openstack/murano/commit/?id=d6456f00d281b6386dd973e7dcc23e1563791c2c
Submitter: Jenkins
Branch: master

commit d6456f00d281b6386dd973e7dcc23e1563791c2c
Author: Stan Lagun <email address hidden>
Date: Mon Aug 1 22:53:37 2016 -0700

    Get rid of type origins

    Due to how versioning works, when class inheritance
    graph for particular class might be changed so that
    there won't be several versions of the same class along
    different inheritance paths if they all can be merged into
    a single class without breaking the requirements.
    This means that parent of some base class might be different
    from those that would be if that base class would created alone.

    Before this commit there was a class remapping table that
    was saying which parent class should be replaced with which
    in the inheritance graph (considering that both classes differ
    in version only). Each class used to have such table. Thus in
    oder to do the graph traversal type origin (root of that graph)
    need to be known in order to obtain remappings table.

    However in certain cases information on type origin got lost.
    For example if one would do cast($obj, Parent).method()
    the method would be looked up in the Parent class and all
    in ancestors like if the Parent was the type origin. This could
    cause different resolution from what would happen if the lookup
    algorithm new that the true type origin is type($obj) instead.

    This commit brings different solution to the original problem
    eliminating the need to know type origin. Instead when the base
    class parents need to be changed, because we cannot change
    the class parents due to the fact that this change is only
    relevant in context of origin type, we create a clone MuranoType
    instance which differs in its parents ony.

    The downside of this solution is that now there could be several
    MuranoType instances representing the same type and attempt
    to lookup the type in its package may return different object
    from what you would get from type(cast($obj, Parent)). This is
    solved by making them comparable (with == and !=). So now
    instead of saying "obj.type is Type" one should use
    "obj.type == Type" instead. Because there is no "is" comparision
    in MuranoPL nothing breaks there from this change.

    Another issue is that there are static properties which values
    must be shared across all type clones. This is solved by making
    a clone with copy.copy() shallow cloning function. Thus internal
    dictionary where property values are stored remains the same
    for all clones.

    Closes-Bug: #1608712
    Change-Id: Ib29f731f2598eaf7e7ea5f69f75e023d7155af5e

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/murano 3.0.0.0b3 development milestone.