Description
We are making our own theme. We have subclassed TriggerFieldDefaultAppearance, but it would be a lot easier if more was protected instead of private. Specifically, the member fields resources and style, and the helper function renderInput(). We are overriding render(), and all 3 of those are used in render. Currently, we have to shadow them, including copy-pasting the renderIntput function into our subclass. Are we doing something unintended here, or should those fields/function be made protected instead?

Most "DefaultAppearance" classes use protected for members and helpers and are easy to override, so I hope this was just an oversight.

Run mode
both

Steps to reproduce the problem

Try to subclass TriggerFieldDefaultAppearance

Override render(), try to use resources and style, or call renderInput

Expected result
Compiles

Actual result
Fails to compile because members are private rather than protected.

Thanks - you make a good point about this. I've just finished a large audit of the use of appearances in widgets (I think you filed this bug earlier) and will have it merged in soon, and this looks like a new target for improvement.

In a pinch, remember that you can write a JSNI getter method for those private fields. Additionally, you can use the constructor as an opportunity to get a reference to that clientbundle and cssResources, though doing so creates another field, which would be good to avoid.

We'll be marking them always as final in an attempt to better communicate that the default implementations are designed to be read, not written, and to be as stateless as possible, as both of these will allow the compiler to do a better job with removing any extra abstractions and writing out faster compiled code. We with need public or protected getters for each of those fields, or to modify those fields to be more readable from subclasses.

15 Oct 2012, 10:45 AM

MarcT

Thanks, Colin, I've been using both the workarounds you suggested.

Marking those fields final is just fine, but in order to do common things like override render(), they need to be protected rather than private. Most of them are "protected final" already, which just makes the ones that are private that much more glaring. I appreciate you recognizing this is a "consistency sweep" kind of bug and not just an isolated incident!