On 7 May 2017 at 15:10, Kjell Ahlstedt <kjellahlstedt gmail com> wrote:
Den 2017-05-06 kl. 23:09, skrev Jonathan Wakely:
On 6 May 2017 at 21:00, Murray Cumming <murrayc murrayc com> wrote:
The old style-enum won't let us change this, in gtkmm 3,
Gtk::RESPONSE_OK
into this, in gtkmm 4:
Gtk::Dialog::Response::OK
without also polluting the API with this
Gtk::Dialog::OK
Using an old-style enum would let us have this:
Gtk::Dialog::RESPONSE_OK,
(and Gtk::Dialog::Response::RESPONSE_OK)
which is still an improvement, but not quite as nice.
Strictly speaking, an old-style enum *and* a scope would allow that.
namespace Gtk {
struct Dialog {
struct Response {
enum ResponseEnum { OK };
};
};
}
That would give you the implicit conversions of old-style enums, but
still give scoped names. That might not be useful, I'm just saying
it's possible.
_______________________________________________
That might very well be useful. A minor drawback is that we would have both
Gtk::Dialog::Response::OK (wanted) and
Gtk::Dialog::Response::ResponseEnum::OK (unwanted). With an unnamed
old-style enum there would be only Gtk::Dialog::Response::OK.
namespace Gtk {
class Dialog : public ... {
public:
struct Response {
enum { OK };
};
};
}
An unnamed enum entails some restrictions, as discussed in
https://bugzilla.gnome.org/show_bug.cgi?id=86864#c34, but that's probably
not important for the very few enums in gtkmm and other mm-modules where we
want implicit conversion to int.
Personally I find the downsides of unnamed enumerations types (can't
overload on the type, don't have a name to refer to the constants even
though they are allegedly related) are much worse than the fact there
are two ways to refer to the enumerations. I've never seen problems
arising from the fact that you could also write
Gtk::Dialog::Dialog::Dialog::Dialog::Response::OK (because of the
injected-class-name) so I don't see why the case you mentioned would
be a real problem.
If you're really worried about it:
namespace Gtk {
class Dialog : public ... {
public:
struct Response {
enum ResponseEnum { };
static constexpr ResponseEnum OK = 0;
static constexpr ResponseEnum ERR1 = 1;
static constexpr ResponseEnum ERR2 = 2;
};
};
}
But I don't think that's an improvement.
