Don't protect options passed to attribute definitions in dashboard config?

[bibliotechy]

When defining an attribute in a dashboard, I can pass arbitrary options parameters to the with_options method, such as

ATTRIBUTE_TYPES = {
    clown_name: Field::String.with_options(
      required: true, 
      extra-html-classes: %w[comic-sans  balloons]),
}

and those options are persisted in the @options instance variable of the Administrate::Field::String object that is available in views.The problem I have is that, @options is exposed through a attr_reader under the protected section of the class, so I can't "safely" access it. I know that I can access options via attribute.send(:options), but I'd prefer to only rely on public methods.

Passing arbitrary options provides flexibility to attribute definitions, allowing me to override less views, and lowering my maintenance burden, both things I like. 🎈 🤡

Is there a significant reason why options should remain protected and not part of the public interface?

Thanks!

[greatseth]

I'm not sure why providing access to options is considered undesirable. It seems that part of the goal is to encourage you to subclass the core Field classes. See #612.

Subclassing core fields is all well and good, but allowing us to customize core fields via options and/or modifying templates seems to be a concern at odds with trying to encourage us to subclass them.

[pablobm]

Closing in favour of #612