I keep butting my head into the lack of an enumeration generics constraint.
I can’t make generic arrays or set types from an enumeration, nor do operations on a variable of that type.
(Disclaimer: The code is for illustration only and may be incorrect or illogical)
TTaskFactory = class
type
TTaskClassArray: Array [T] of TTaskClass; //<– illegal
TTaskSet: Set of T; //<– illegal
private
class var FFactory: TTaskClassArray;
protected
FAllowedTasks: TTaskSet;
public
class procedure RegisterTask(const Id: T; aTaskClass:TTaskClass);
function MakeTask(const Id:T):TTask;
property AllowedTasks read FAllowedTasks write FAllowdTasks;
end;
class procedure TTaskFactory.RegisterTask(const Id: T; aTaskClass:TTaskClass);
begin
Log(‘Registered Task Id ‘+IntToStr(Ord(ID))); //<– illegal
FFactory[Id] := aTaskClass; //<– illegal
end;
function TTaskFactory.MakeTask(const Id:T):TTask;
begin
if Id in AllowedTasks //<– illegal
then begin
if Assigned(FFactory[Id]) //<– illegal
then Result := FFactory[Id].Create //<– illegal
else raise EProgrammerNotFound.Create(‘Forgot to register’);
end
else Result := nil;
end;
If only I could write:
TTaskFactory = class
TSoTaskType = (ttMakeItSo, ttSoBeIt, … ttSoWhat)
TSoTaskFactory = class(TTaskFactory);
I am sure there are other examples, but I really miss being able to do
declarations and operations like these in a generic class:
Arrays, sets, low/high, ord, in, pred/succ, and related operations.
Yes, there are better ways to do class factories, and I use them – but the Enumeration constraint would enable so many possibilities.
Mason Wheeler Faith is no grounds for such a discussion.
David Heffernan …huh?
Mason Wheeler Faith. When one believes something irrespective of evidence. You have no evidence that C++ is more prone to buffer overruns. You just believe it. Creating a string from a literal in C++ is not a source for buffer overruns. But you don’t care about the facts. Your mind is already set.
David Heffernan The evidence speaks for itself: programs written in C++ regularly suffering disastrous data breaches due to buffer overruns, and hurrying to put out patches to prevent exploits on a monthly basis. What greater evidence do you need than that? My mind is already set because of the evidence, not in spite of it!
Mason Wheeler Well written C++ is no more susceptible to overruns than well written Delphi. You seem confused between C and C++ amongst other things. Where are these well written C++ programs that are built on the STL and have buffer overruns. You see defects in Windows and Linux and OpenSSL etc. and think that means that C++ is defective. That’s comical. I’ve said enough.
David Heffernan That’s the whole point: “Well written C++” does not exist! It’s a theoretical construct that can be approached in practice, but the language is stacked against you, making it so easy to get things wrong that even the most experienced developers keep writing buffer overflows year after year, decade after decade, program after program.
You see defects in some of the most prominent C++ products and think that somehow means the language is not defective? That’s insane.
Mason Wheeler You are wrong. Well written C++ exists. The programs with defects to which you refer are mostly written in C. Poorly written code exists in Delphi. Its just as easy to do in Delphi.
Pointing to stats is naive because of the relative rarity of Delphi code in headline programs. Which major program which gets airplay when defects are found is written in Delphi? Name one.
Anyway I’ve said my bit. I’ll change my mind when you show a technical reason to back your claims. With reference to the languages.