lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] [lmi-commits] master 084f1b49 5/5: Make a different virtual pu


From: Vadim Zeitlin
Subject: Re: [lmi] [lmi-commits] master 084f1b49 5/5: Make a different virtual pure
Date: Sat, 16 Jul 2022 17:29:31 +0200

On Sat, 16 Jul 2022 15:24:56 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 7/16/22 14:55, Vadim Zeitlin wrote:
[...]
GC> > Unfortunately I don't
GC> > understand the purpose of this class fully enough to propose a concrete
GC> > solution, e.g. I have no idea why do we have block_keyword_values()
GC> 
GC> Expunged.

 Thanks, I should have waited a bit longer with my reply...

GC> >  But if I were writing a class like this today I wouldn't have two
GC> > different interdependent virtual xxx_values_are_allowable() functions but
GC> > would rather have just a single get_allowable_values_kind() returning an
GC> > element of (scoped) enum with values Numeric, Keyword and Both (but not
GC> > "None"). This would make it impossible to write, or at least to compile,
GC> > insane code in the first place.
GC> 
GC> Interesting point. But if we were writing a set of classes like
GC> this today, would we agree that inheritance is the best way to
GC> tie them together?

 Probably not, as there doesn't seem to be any need to handle them
polymorphically (nor even any useful virtual functions that could satisfy
such a need). So using compile-time polymorphism could indeed be an even
better idea -- but one which, I suspect, you're even less inclined to
pursue, so I won't explore it further.

 Regards,
VZ

Attachment: pgpRaYKjCS2A6.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]