UISprite: virtual fill functions?

[Gryphon]

Hello!
Could you please make UISprite fill functions (SimpleFill, SlicedFill etc) virtual? I want to create custom sprites derived from UISprite, so it would be very usefull.
By the way, why was OnUpdateUVs removed? It is also needed for custom sprites.

[ArenMook]

If you're deriving from a UISprite, just overwrite the OnFill function instead.

OnUpdateUVs was removed because the logic happens in UpdateUVs function which handles "if this is a sliced sprite do this" kind of stuff.

[Gryphon]

If you're deriving from a UISprite, just overwrite the OnFill function instead.

I do so, but overwriting fill functions would be better in architectural way. For example I could overwrite fill functions only for sprite type I really need. For now I use base.OnFill in this case but I don't like it. So not that it's the thing I can't live without, but it would be appreciated 

OnUpdateUVs was removed because the logic happens in UpdateUVs function which handles "if this is a sliced sprite do this" kind of stuff.

Yes it does but UpdateUVs isn't virtual as OnUpdateUVs was, so I can't overwrite it for my sprites without copying your code. Even if it would be virtual, I would have to copying "was UV really changed" condition which would be not a big problem but still less handy then overwriting special function for this case.

To be honest, I can't see much difference between how OnFill and (On)UpdateUVs should be used by derived classes. In both cases user wants to directly overwrite what will happen to his sprite without copying UISprite's code. From this point of view (IMHO) sprites before 2.5 were more flexible.

[ArenMook]

Be as it may, the ability to change the sprite type on the fly in inspector far outweighs this disadvantage. I will make the functions you mentioned protected so they are accessible from derived classes. I don't see why there is a need to make them virtual. I will make UpdateUVs virtual though.

[Gryphon]

Be as it may, the ability to change the sprite type on the fly in inspector far outweighs this disadvantage.

Of cause it does! It is really great and impressive feature!

I will make the functions you mentioned protected so they are accessible from derived classes. I don't see why there is a need to make them virtual. I will make UpdateUVs virtual though.

Thanks you for this.