Re: extending c++ classes and enumerations
* perrog@gmail.com:
Alf P. Steinbach skrev:
* perrog@gmail.com:
// File enum.h
enum ThreadState { ERROR = -1, RUNNING, TERMINATED };
extend enum ThreadState { CANCELED };
Thanks in advance.
Yes, it could be useful, but... ;-)
First, when extending an enumeration type you're up agains the "Is a
circle an ellipse" conundrum. The answer is, a const circle is a const
ellipse. For a non-const circle it's not so; consider
...
Second, enumerations are generally -- not in all cases but generally
-- a sign of purely procedural non-OO code, which could much better be
recast at the design level in some OO way than focusing on language
level patches to the some of the mildest symptoms the code exhibits.
So you mean that to make this story work properly, C++ would require
another keyword, say "set", and statements like.
No.
I'm saying (1) there is a circle/ellipse issue, but in reverse,
ExtendedEnum derived from Enum is like an Ellipse derived from Circle
(some ellipses are circles), and (2) enumerations, especially those that
seem to need some extension, are indicative of improper design.
I thought that was what I wrote.
But just to be clear, regarding (1), one might imagine a language
extension allowing
enum E {a, b, c};
enum EEx: E {d, e};
where the set of values for EEx is {a, b, c, d, e}.
Now consider assignment compatibility. eex_var = e_var should be
allowed, since the "proper" value set of eex_var includes that of e_var.
e_var = eex_var should not be allowed without a cast, because the
"proper" value set of e_var does not include all possible values in
eex_var. Thus, the IS-A relationship goes the opposite way of what you
get with class inheritance: it's EEx that corresponds to a Base class,
and E, the original, that corresponds to a Derived class; E IS-A EEx.
Then, building further on the above logic, consider
typedef EEx Base;
typedef E Derived;
void foo( Base& v ) { v = e; }
and calling it thusly:
Derived e_var;
foo( e_var );
For ordinary classes this is allowed but results in a slice (which is
generally bad). For enumerations it results in violating the ideal type
rules, with e_var ending up with an "invalid" value, e.g. one that that
doesn't correspond to any 'case' in a 'switch' on this variable, and so
not diagnosable. Thus, the IS-A relationship is strictly a const
relationship: a const E IS-A const EEx, but that's all.
This is quite foreign to C++: contravariant IS-A, and limited to const.
It is perhaps not unsurmountable, but it would be nicer to have it as a
kind of more general language mechanism able to cope with e.g. those
darned Circles and Ellipses, not to mention Integers and Rationals.
[snip]
By the way, all uppercase should be reserved for macro names.
All uppercase for macros is an old convention dating back at least to
K&R C, wherefrom Java picked it and associated it with a slightly
different meaning, incompatible with the C and now C++ rationale, so the
above is indicative of Java background -- don't do that in C++ code.
That is absolutely not related to C++ grammar. :-)
It is. A main reason for the convention is that macros don't respect
the ordinary grammar rules. In particular, they don't respect scopes.
Similar "convention" seems to be applied to accessors.
class Employee {
Employ& setName(const std::string &name);
std::string &getName();
const std::string &getName() const;
std::string name;
};
and this creates a property, an intermediate form between structure
function and field.
And used like
Employe person("Roger");
cout << person.Name << endl; // prints "Roger"
person.Name = "Fritz";
cout << person.Name << endl; // prints "Fritz"
There is a Java web server, where the view layer that generates XML
code maps similar kinds of Java functions to a data accesors in a
PHP-Smarty similar language. I personally think Microsoft's C# accessor
syntax is the "correct" way to handle accessors,
class Employee {
Name { get { return name; } set { name = value; } }
String name;
};
Have only heard rumours about Objective-C 2.0 @property syntax, but not
checked it yet.
Anyway, with the current RTTI level in C++, I think naming convention
plays a minor role. :-)
Naming conventions play a very important role where macros are
concerned. But I agree that the Java "get" convention has no place in
C++, at least with the current standard's lack of introspection support.
"getsin", bah, we have the internet for that. ;-)
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]