The multiple inheritance problem

[ArielLorenzo-Luaces]

I'm having an issue where I need to implement a class that can be used as a texture and can be sent to SPImage and such.
Normally I would subclass SPTexture and override whatever I need to implement my new functionality.
However in this case I also need to subclass another class from a closed source library.
But without multiple inheritance this can prove challenging

One solution I came up with is to change sparrow so that instead of SPTexture being used directly by other classes such as SPImage, there could be a texture interface for SPImage to interact with.
Then all I would need to do is subclass that other closed source library and then implement sparrow's SPImage's texture interface. Followed by an implementation of all the interfaces methods.
This way I can completely bypass SPTexture and can still get SPImages to show without any hassle.
In the end, SPImage couldn't care less what class it's interacting with as long as the class is providing the texture methods that SPImage needs.

I'm really just writing this to see what other people think. That's why I didn't make a pull request.
The changes:
https://github.com/arielsw/Sparrow-Framework/commits/90c7330be4310779395f0f230a4db0f15e341e28

[PrimaryFeather]

Hi!

Couldn't you solve your problem through composition instead of pure inheritance? You could subclass SPTexture and have an object of that other class as a member of that texture. Then you could override the SPTexture methods, forwarding some of the functionality to that object.

Using interfaces -- that is: protocols in ObjC -- here seems quite a big change to me. I'd rather avoid that!

[ArielLorenzo-Luaces]

Hi Daniel, Thanks for the reply

Lets say I decided to instead subclass "that other class" and made an SPTexture object as a property inside my new MyTexture class. Then in order to send it to SPImages I guess I could just initialize the image with the SPTexture object that belongs to MyTexture. Well that's no big deal.
If internally, the texture name of MyTexture changes I guess I could change the name in the SPTexture.
EDIT: Actually no I can't, because the name property of SPTexture is read only.
If the "adjustVertexData:atIndex:numVertices:" method gets called in SPTexture I need to intercept it and handle it in MyTexture. However I can't do that either because that would require editing SPTexture to maybe forward its "adjustVertexData:atIndex:numVertices:" calls to a delegate. Actually I can't do it in SPTexture because only the subclasses of SPTexture implement "adjustVertexData:atIndex:numVertices:". So I guess I have to pick, lets say SPGLTexture to use the delegate.
EDIT: Or make my own MySPTextureSubclass that implements this delegate functionality.

EDIT: This method could be problematic whenever I need to implement new functionality at the time a method of SPTexture is called. Lets say I need to record the time at which the texture "name" is requested. I can't do it without changing the functionality of SPTexture. Maybe by subclassing SPTexture as well as using composition? hmm...

The exact same scenarios could potentially arise if I were to to the opposite and subclass SPTexture and have an object of "that other class"

Doing any of this stuff seems more complicated than just interfaces and implementing the SPImageTexture interface in my MyTexture class. Followed by implementing all the methods that correspond to it (Which I have to implement anyway):
frame
width
height
premultipliedAlpha
adjustVertexData:atIndex:numVertices:
repeat
smoothing
name

Also all these changes I made with interfaces had a zero effect on any functionality whatsoever. Since all interfaces do is say "This class has this set of methods" and the classes that were already implementing these methods will still be implementing these methods, nothing can really brake. It doesn't even change the external use of Sparrow. A user would still create an SPTexture and pass it to an SPImage because SPTexture implements the ISPImageTexture interface.

Thanks for discussing this with me, I'm trying to figure out a good way to go about this.
And maybe in the future if someone has a similar issue, they just need to read this discussion.

[PrimaryFeather]

Thanks, to you as well for the suggestions! That's the first time this topic comes up in both Sparrow and Starling.

May I ask for more specific information about the actual use-case? What is this other class we're talking about?

[ArielLorenzo-Luaces]

The other class is from a library that is capable of managing OpenGL texture data
The library is mainly comprised of
a TextureManager static class
and a Texture class that represent all my separate textures
The library is capable of generating a texture atlas of multiple textures at run time. To do so it updates the Texture object's name and information about where on the OpenGL texture my texture data can be found (position and size)...
I'm also capable of setting a memory limit and the TextureManager will release unused textures based on texture usage data I give to the TextureManager.
The TextureManager is also capable of comparing textures on the backend and reusing textures loaded for different objects (if they are the same of course).
There are also additional tools for texture manipulation: blurring, blending textures, bloom...

All of this is through the use of the Texture objects. The name, origin, and size properties of the Texture object change often and I need to keep the SPTexture information up to date so that SPImage can render the right thing.

EDIT: In my opinion both Sparrow and this closed source TextureManager library should make use of interfaces. I could have an interface with a bunch of setters so that the TextureManager can send me its data and Sparrow could have an interface with a bunch of getters so that I can process the information and make it available to Sparrow. Neither Sparrow nor the TextureManager library should force me to subclass their class when it's clearly not required with interfaces (Keep in mind that Sparrow could still make available a kind of default texture class that can still be subclassed, and everything would work exactly the same as if interfaces didn't exist). That way it leaves me the flexibility to subclass anything I want, maybe even my from my own set of classes.