Make tokenizer, backbone, preprocessor properties settable on base class

[mattdangerw]

This improves the readability of our subclasses, instead of writing to a hidden property self.backbone and reading from self._backbone, we can use a consistent style everywhere.

[mattdangerw]

Curious what everyone thinks of this. IMO the base classes have overall been great, but one inscrutable and overly magical eyesore is we are writing self._backbone in our task constructors, then self.backbone in call. It's totally confusing and not at all clear this is part of the contract with our base class.

The settable property pattern is something we do in core Keras, so it seems consistent to pick up here. See this line for example.

You could make an argument that we don't want these settable at all (we should protect users from themselves), but I'm not sure that's really that consistent with the rest of our model offering. After all preprocessor.sequence_length, and backbone.hidden_dim are totally settable, we just aren't recommending it.

So anyway tl;dr, I think we should focus on our task model readability here, and I think this is an improvement!

[jbischof]

Seems reasonable, but I think initially we weren't sure we wanted them to be settable to minimize user confusion. For example on Task models you could set model.preprocessor but not understand that unless you also set model.include_preprocessing = True it won't work. It seems like our designs need a higher standard to fulfill the user expectations no?

[mattdangerw]

For example on Task models you could set model.preprocessor but not understand that unless you also set model.include_preprocessing = True it won't work.

This is actually a one liner fix, and seems reasonable to add. Just put it in.

Though overall, I'm not saying we should ever advertise that this property is settable (just like we don't advertise that you can do preprocessor.sequence_lenth = 64). Mainly want the focus on consistent and readable task modeling code.

If not this, maybe we should override our property definitions similar to what we do for the recently added backbone.embedding_layer, so we don't leak private data across class boundaries wherever possible.

[jbischof]

Great, as long as we do the work to ensure that these properties can be manipulated intuitively it seems like a better experience. I thought of one bug but there might be others.