Generics T constraint
Generics T constraint
TMyClass = class
private
FReference: T;
public
property Reference:T read FReference write FReference;
end;
T needs to be either a class or a record but you can't combine those constraints. The obvious workaround is
TMyClassC = class(TMyClass);
TMyClassR = class(TMyClass);
That is a bit annoying :P
TMyClass
private
FReference: T;
public
property Reference:T read FReference write FReference;
end;
T needs to be either a class or a record but you can't combine those constraints. The obvious workaround is
TMyClassC
TMyClassR
That is a bit annoying :P
Better to use a runtime test in my view. Pretty unusual to want to constraint to be either class or non-nullable value type. Your property declaration is not valid.
ReplyDeleteWe need to make a big list of all the things that should change in generics (and constraints) and put them in a single big QP.
ReplyDeleteDavid Heffernan I guess you can say the declaration is "meta code" and it is left to the reader to imagine the field/setter/getter.
ReplyDeleteThe reason for desiring the combination of these two, is that both have fields and properties which can be RTTI enumerated the same way.
ReplyDeleteSo use a field and this make the code even short, and also valid. You post a lot of code of this nature that does not compile and so forces anyone trying to help you to do extra work. Not an issue here, but it has been on other times.
ReplyDeleteDavid Millington There should probably one "mother QP" which link the issues - but it usually is a good idea to separate requests/reports.
ReplyDeleteDavid Heffernan The point of constraints are type safety to catch mistakes at compile time. I would prefer not to give that up for run time checks - although those are a fallback method.
ReplyDeleteDavid Heffernan Point taken on compilable code example, although Ctrl+Shift+C would have completed it into valid code.
ReplyDeleteI understand what constraints are for, but I'm not sure that what you have produced is better. It just adds confusion and clutter to my mind. I think the downsides outweigh the gains.
ReplyDeleteI'm curious though, why do you want to restrict to classes or non-nullable value types? That seems unusual.
Because the class will enumerate the fields and properties of type T, looking for specific attributes, and it would be undesireable to have T's which are not classes or records.
ReplyDeleteI'm still hanging out for typesafe "duck-typing" in Delphi. Ie, if a type implements an interface, even by accident (not specifying that interface), allow it to be treated as an instance of that interface. That would be useful in many areas, not just generics.
ReplyDeleteLike strings, or interfaces, or anonymous methods? It sounds odd that an array of characters would be valid, but a string would not. Or an integer would be valid but a string would not. Or a record containing a single string would be valid, but a string would not.
ReplyDeletePerhaps the a new constraint could actually be structure to separate it from simple types.
ReplyDeleteTMyClass
And there we have it. The record constraint does not restrict you to compound structures declared with the record keyword. Simple types meet the record constraint. So Integer and double both meet the record constraint.
ReplyDeleteDavid Heffernan I did not know that. Even more reason for a structure or compound constraint.
ReplyDeleteThis is why I tend to ask why rather than give the naive answer. Doing so often reveals something of use. You recently suggested that I should not do that. I think it's more useful to poke and prod at the reasons behind a question or post.
ReplyDeleteBut all the same, I cannot see why you would be interested in providing a facility that only worked for compound types. That seems needlessly limiting. Aren't you going to end up making the code less capable than it needs to be?
ReplyDeleteI am trying to make it less complex by eliminating capabilities that are not needed, and hence reducing the test scopes.
ReplyDeleteI don't mind your questions when they are constructive.
My children ask me stupid questions sometimes. It's better that they did that than never to ask at all.
ReplyDeleteThere are no stupid questions, IMO, but - to quote the despair.com T-shirt - " - there are a lot of inquisitive idiots." 😇
ReplyDeletehttp://despair.com/products/cluelessness