On 01/15/2015 09:05 AM, Ian Kelly wrote:
On Thu, Jan 15, 2015 at 12:23 AM, Andrew Robinson
<andr...@r3dsolutions.com> wrote:
Can you name any other language that *does* allow subclassing of
booleans or creation of new boolean values?
Yes. Several off the top of my head -- and I have mentioned these before.
They generally come with the extra subclasses pre-created and the user
doesn't get to create the classes, but only use them; none the less -- they
have more than two values with which to do logic equations with.
VHDL, Verilog, HDL, Silos III, and there are IEEE variants also.
C/C++ historically allowed you to do it with instances included, although I
am not sure it still does.
Sorry, let me rehprase my question. Of course there will be
special-purpose languages that allow you to do interesting things with
the logic values and operators. Can you name any other
*general-purpose* language that allows subclassing of booleans or
creation of new boolean values? If not, it seems rather unfair to
single out Python and marvel that this isn't allowed when it's
actually quite normal to disallow it. Unless you care to provide an
example, I am fairly sure your claim of C/C++ is wrong. The bool type
in C++ is a primitive type, none of which can be inherited from. C
doesn't even have a bool type; at most you have macros for true and
false to 1 and 0, so the "booleans" there are just ordinary integers.
Ian,
I agree with you mostly; there is good reason to pick on other
languages, too, with respect to what a bool is.
Although, I have to laugh -- Verilog can syntheze a CPU -- implement
memory -- and then load a program and run python on the virtual
machine. When the pentium was first developed, I watched as Intel
actually booted up MS-DOS under using Xilinx chips to run the verilog
program's output they could physically run anything a pentium processor
could run. That's *IS* what I consider "general purpose".
But you're sort of confounding my need for type information in my new
class as a way to advertise compatability with bool, with subclassing --
which is only one way that I was exploring to get the 'type' name
attached to the new object; That's a mistake that D'Aprano seems to be
repetitively making as well.
But please note: Type checking for 'bool' is only needed for
legacy/compatability reasons -- but new code can use any type; so
subtyping is not strictly necessary if there is another way to get the
'bool' type attached to my return object for advertising purposes; for
what I am interested in is an object who presents as bool for legacy
code, but new code can convert it to anything at all..
C++ *DOES* allow the necessary kind of type checking and subclassing for
what I need to do in spite of not having a subclass mechanism built into
the language for base types; eg: C++ allows a semantic subclass to be
constructed which can be typecast to a bool for compatibility, but
otherwise presents extra data and the type the enhanced object reports
is irrelevant. As I've mentioned before, people can do object oriented
programming in C, So, to satisfy your curiosity -- I'll show you a
mixed C/C++ example, where I make a semantic subclass that has five
values AllFalse, PartFalse, Uncertain, PartTrue, True ; and these five
values will have a typeid() of bool and be 100% compatible with legacy
C++ bool; but upon request, they these 'bool' types will re-cast into a
semantic subtype that provides additional certainty data.
See the program at end of e-mail. It compiles with gcc 4.8.2 with no
warnings; g++ filename.cc ; ./a.out
But let me explain a bit more why I'm picking on Python: For even if we
set the electronic engineering concerns aside that I've raised (and they
are valid, as OOP is supposed to model reality, not reality be bent to
match OOP) -- People's facile explanations about why Python's version of
bool is the way it is -- still bothers me here in the python mail list
-- because people seem to have a very wrong idea about bool's nature as
a dualton being somehow justified solely by the fact that there are only
two values in Boolean logic; For, singletons style programming is not
justified by the number of values an object has in reality -- And I know
Charles bool didn't use singletons in his algebra, -- just read his
work and you'll see he never mentions them or describes them, but he
does actually use dozens of *instances* of the True and False objects he
was talking about -- for the obvious reason that he would have needed
special mirrors, dichroic or partially silvered, to be even able to
attempt to make one instance of True written on paper show up in
multiple places; And that's silly to do when there's no compelling
reason to do it.
Yet -- people here seem to want to insist that the bool type with only
two *instances* is some kind of pure re-creation of what Charles Bool
did -- when clearly it isn't. It's a amalgamation of enhancements such
as binary words instead of just True/False and many other things
(operators that work on words rather than single bits.). So -- I don't
see that Python's implementation of Bool is justified by either a purist
appeal to Charles bool, or by ignoring pragmatic concerns that have been
attached to Bool's work for years by Electrical Engineers in order to
make it more useful for *practical* computer problems. Yet these two
things are what this python list has sort of harped on.
That brings me to your point about other languages; I think following
other languages restrictions arbitrarily is potentially a lemmings
approach, eg: just because 'everyone' is doing it statistically does not
mean that it is good to do it that way; If many languages do something,
there is excellent cause to examine and look for reasons 'why' they do
that (and I'd love to hear your opinions) but Python has a different set
of constraints as an interpreter, as opposed to a compiler, and many
other differences which cause unintended side effects when mimicking
other programming languages. It's the unintended side effects and
surprises when a hasty decision is made that's the issue here.
Where python is different from other languages regarding bool -- and
deserves a little extra picking on, is that Guido has imposed four
constraints *simultaneously* to bool which together cause a conflict
that I don't think (offhand) I've ever encountered in another language;
Definitely not in C/C++!
The four things are: 1 -- he cut off subtyping and created no alternate
method of doing type checking of duck-types, 2 -- he does not allow
multiple instances, 3 -- he himself did not implement bool using the
standard alternative methodology to subclassing -- eg: as a composite
structure with delegation. 4. and he has made bool into the default
return type for base type comparison operators; which means that general
programmers expect a bool for base types and may check for it, even if
Python's built in functions do not.
If any one of these four things had not been done, I would not have
reason to complain about bool in Python; because there would be a way
for me to easily work with people expecting a bool as a return type from
comparison operators, using standard OOP techniques and a little
creativity to make something perfectly compatible; rather than having to
dig through manuals endlessly with conflicting notions, pep's, and
subtleties that make for an extremely steep learning curve and lots of
time spent making only slight progress when there's not much *reasoning*
behind what Guido did which is consistent and useable as a guideline...
As far a subtyping goes; The very fact that Guido used subtyping to
create bool in the first place (subtype of int), precludes any real
claim that bool should not itself be subclassable just because bools
only have two values; I mean, seriously -- Guido's 'strict' Bool is
already an impure form of OOP that is borderline hypocrisy, as it can
'+' to 2 or 3... and many other things; and worse I've just come across
a couple of papers which suggest that Guido doesn't like subclassing
when Composite object structures could be used instead to replace the
subclass 'is' relationship with a 'has a' relationship. So -- if that's
the case, why isn't bool a composite to begin with ? eg: Guido's
programming guides must be read with a caveat 'do what Guido says and
not what Guido does' ?!
Now to your last point -- I need to point out that C++ does not have
all four restrictions I've mentioned so it doesn't have the problem
Python does; In C++, there are instances of bool, and therefore I can
easily encode extra information in a bool object without changing the
object itself.
Here's a skeleton example, where I only implement one operator '<' on
the semantic subclass, but the example shows the principle of how to
extend the bool type via typecasting to bool. There are better ways of
doing this, and there are some problems with how I implemented esp. as
many use cases are not properly covered -- but it serves to show that
C/C++ CAN encode new subtypes (semantic subtypes only not C++ subtypes)
while using only the base type itself to transmit data in a perfectly
backwards compatible way. In Python, however, it's pretty close to
hopeless...
#include <iostream>
#include <typeinfo>
using namespace std;
// Create a new super-bool type which is semantically a subtype of bool,
// But have it masquerade as a bool for compatability, unless new code
// explicity typecasts it and access its subtype members.
struct _SBool {
bool basebool;
int certainty;
};
class SBool: public _SBool {
public:
SBool( const bool& );
bool operator < (const SBool &);
};
// Create all 4 of the statistical uncertainty values as penta-ton.
const _SBool bools[5] = {{false,0},{false,1},{false,2},{false,3},{true,4}};
// Create 4 global alias bool names having full compatability with bool
// for legacy code, but useable in mixed or advanced compares.
const bool & AllFalse = bools[0].basebool; // uncertainty 0
const bool & PartFalse = bools[1].basebool; // uncertainty 1
const bool & Uncertain = bools[2].basebool; // uncertainty 2
const bool & PartTrue = bools[3].basebool; // uncertainty 3
const bool & True = bools[4].basebool; // uncertainty 4
// Create the typecast method.
SBool::SBool( const bool &b ) {
const void* that = &b;
if ((that >= bools) && (that < bools+5)) *this=*(const SBool*)that;
else *this=*(const SBool*)(const void*) &(b?True:AllFalse);
bool SBool::operator < (const SBool &other ) {
return this->certainty < other.certainty;
}
// ------------------------------------ Test harness.
int main(void) {
cout << "type match=" << (typeid(bool) == typeid(AllFalse)) << endl;
cout << "testing as bool " << AllFalse << PartFalse <<
Uncertain << PartTrue << True << endl;
cout << "testing as SBool " << SBool(PartFalse).certainty <<
endl;
cout << "testing up-cast false " << SBool(false).certainty << endl;
cout << "testing up-cast true " << SBool(true).certainty << endl;
cout << "testing advanced compare (should be true)" <<
(SBool(AllFalse) < PartFalse) << endl;
cout << "testing legacy compare (should be false) " << (AllFalse <
PartFalse) << endl;
return 0;
}
//------------------------------------ End of program, Test output
follows -------------------
type match=1
testing as bool 00001
testing as SBool 1
testing up-cast false 0
testing up-cast true 4
testing advanced compare (should be true)1
testing legacy compare (should be false) 0bash-4.2$
--
https://mail.python.org/mailman/listinfo/python-list
