Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IO Coder ProxyType concept seems broken #77

Open
luithefirst opened this issue Jun 10, 2022 · 1 comment
Open

IO Coder ProxyType concept seems broken #77

luithefirst opened this issue Jun 10, 2022 · 1 comment

Comments

@luithefirst
Copy link
Member

luithefirst commented Jun 10, 2022

Does anyone remember what use cases ProxyTypes are for and how they are supposed to be used?

I for example have these, but actually I no longer directly code PixImages for quite a while:

Aardvark.Base.Coder.TypeInfo.Add(new Aardvark.Base.Coder.TypeInfo(typeof(PixImage<float>), () => new PixImageProxy<float>())
            {
                Object2ProxyFun = x => ((PixImage)x).ToFieldCoderProxy(),
                Proxy2ObjectFun = x => ((PixImageProxy)x).ToPixImage(),
                ProxyType = typeof(PixImageProxy<float>)
            });

I believe they were necessary because there was some restriction with generics. I would need to create an example with PixImage to see how this would have worked, but actually, a see some flaws in the coder when proxies are used.

The creator of the TypeInfo "() => new PixImageProxy()" creates this proxy object. When this is used in the coder during deserialization the Line:

if (m_doRefs) AddRef(obj);

stores a ref to the proxy object and when the ref is used later you get an InvalidCastException.
Note: Within CodeFields, a ref to the parent object may also already be used, but the Proxy2ObjectFun would only be invoked after this, so the actual object to where these refs should point to does not exist yet.

I don't see how this could be fixed, only by redefining how proxies work (decode):

  • The creator would need to create an object of the TargetType
  • "obj" would then immediately have the proper target type and the proper ref could be recorded
  • additional an instance of ProxyType needs to be created and used for serialization (CodeFields)
  • The Proxy2ObjectFun would then also get passed the already created instance and could initialize it with the data from the proxy object
  • Todo: Review encode

A ran into this issue because I currently somehow need to convert an object from an old type to a new type. The new type however is not actually new so when I would simply redirect the types (decode "OldType" as "NewType"), I cannot distinguish between data from "OldType Version=X" and "NewType, Version=X".

(Since I actually do not have refs to the parent object that I want to convert with a proxy, we could simply store the objRef index and overwrite it after Proxy2ObjectFun is invoked.)

The next thing I tried to is register Converters, starting with "Aardvark.Base.Coder.TypeInfoVersion.Add", but I did not manage to register them property yet. When I look at the code here:

newTypeInfo = typeInfo; typeInfo = oldTypeInfo;

newTypeInfo would always be the TypeInfo that was retrieved using the coded type name (OldType). The Name used here:
var target = new Convertible(newTypeInfo.Name, null);

is then the OldType but should actually be NewType. Since Name actually a string, I maybe can somehow create such a custom type info... Then I "only" need to register the converter properly, TypeInfoVersion.Add does not do this (does not run into the proper cases), or I just have not figured out how.

Does anyone still have Converters around? Any help is appreciated!

@luithefirst
Copy link
Member Author

I somehow managed to use the convertes, but they (of course) have the same issue as proxies with references. In order to solve this for now (me), I have implemented that the references are replaced after proxy or converter conversions. So they can be used as long as references to converted objects are not coded in their sub-objects.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant