-
Notifications
You must be signed in to change notification settings - Fork 83
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
The multiple inheritance problem #9
Comments
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! |
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. 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): 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. |
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? |
The other class is from a library that is capable of managing OpenGL texture data 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. |
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
The text was updated successfully, but these errors were encountered: