Renaming properties when inherited from another widget

[tkrugg]

let's say i'm building a Sidepane widget, and I would like to inherit from deliteful/Toggle. That's nice because it gives me for free a nice API to toggle the sidepane and keep track of its state. While the inherited method toggle() makes perfectly sense for a Sidepane widget, the property checked sounds too much like we're dealing with a checkbox.

I'm wondering if there's a way to rename that property (to something such as isVisible), so that it makes sense in the context of the widget we're composing.

[AdrianVasiliu]

My take: even if there would be a technical way to allow a subclass to rename a property of its superclass, I wouldn't think this would be desirable. At least in our current inheritance philosophy, just as in regular OOP, I think such a modification of the API of the superclass is even worse than some liberties we already take, such that a subclass which forbids some values of properties that are valid on the superclass. Less we go such a way, better it is, in my eyes.

If most of Toggle's API (to take your example) makes sense for SidePane, while Toggle hasn't been designed generically enough to fit as superclass of SidePane, instead of artificially forcing Toggle to fit, we could consider modifying it such that it becomes more generic, or creating a new generic superclass that both Toggle and SidePane would extend.

[wkeese]

I agree w/@AdrianVasiliu, it just sounds too complicated to support that.

[cjolif]

Agreed. If we really have actual cases like that maybe the base class property should be renamed to be more agnostic but I don't think we should invent a new kind of OOP. And if we did that would be more for dcl than delite I supposed. I suggest closing this as won't fix?

[wkeese]

OK, sorry @tkrugg but closing this.