[haiku-development] Re: Glass Elevator proposal: templated BControl

  • From: waddlesplash <waddlesplash@xxxxxxxxx>
  • To: Haiku Development ML <haiku-development@xxxxxxxxxxxxx>
  • Date: Tue, 10 Jul 2018 18:04:14 -0400

On Tue, Jul 10, 2018, 5:57 PM John Scipione <jscipione@xxxxxxxxx> wrote:

Dear Haiku Developers,

This letter is meant to start a discussion of a potentially
glass-elevator backwards-compatibility breaking change that I'd like
to propose. The idea is to introduce a templated BControl which takes
a type to use in its Value() and SetValue() methods instead of
assuming int32. I asked about the idea on the mailing list a while
back and it seemed like there was some interest in the idea so I
wanted to get the mailing lists feedback next.

Currently the value of fa BControl is always of type int32. This falls
down when the value of a BControl does not neatly fit into an int32.
For most controls like in the IK like buttons, checkboxes this is not
a problem, however, one example from IK that suffers is BColorControl
which tries to take an rgb_color value. In this case the API gets
around the int32 type limitation by packing an rgb_color stuffed into
an int32 into BColorControl::SetValue() method and implementing
ValueAColor(). Another place where I ran into this deficiency was in
BDecimalSpinner where I overloaded SetValue() to take a double. The
overloaded SetValue() method requires the caller to do casting or
specify their types carefully on the implementation side in order to
avoid ambiguous type warnings/errors.


The point of templated classes is to abstract functionality that does not
depend very strongly on type, but rather is some sort of structure that
will be reused across types, e.g. lists. In this case, however, unless I am
mistaken the only things in "common" are getter/setter functions, which
here take an int32.

So perhaps the better question to ask is "why should BControl know anything
about the type of data it's working with?" Then we would remove
SetValue/Value from the base class and move it just to subclasses. After
all, the vast majority (if not actually all?) users of BControl will be
calling the base class method anyway, and I don't know what value the
current system has in this abstraction.

This is what Qt does at least, and I imagine most other toolkits behave
similarly. We are of course free to be different, but I think we should
only be so when it makes sense to; and I don't see that here.

-waddlesplash


Other related posts: