Two sunday wishes !
Two sunday wishes !
Generic intrinsic constraints, to allow for example:
type
TFoo=class
Data : T;
function Bar:Boolean;
end;
function TFoo.Bar:Boolean;
begin
result:=Data>123;
end;
and relaxed generic recursive declarations for records (FPC 3.0 is going to allow this)
type
TFoo=record // "class" works fine
Data: Array of TFoo;
end;
Generic intrinsic constraints, to allow for example:
type
TFoo
Data : T;
function Bar:Boolean;
end;
function TFoo
begin
result:=Data>123;
end;
and relaxed generic recursive declarations for records (FPC 3.0 is going to allow this)
type
TFoo
Data: Array of TFoo
end;
David Berneda Far better than constraining a type to come from a specific set of types would be to constrain that a type supports a specific operator. In your case you merely need the presence of a greater than comparison. Being able to constrain for operators would allow a whole range of numerical programming to become much cleaner.
ReplyDeleteHowever, it will never happen because the design of generics simply does not support it. We'd need templates for this to be viable.
Union types a-la TypeScript can be handy too: type Number=Integer or Single or Double.. etc
ReplyDelete+David For your example, it's not helpful. You want to write an algorithm, and then decide later which types to apply it to. You want to be able to re-use the algorithm and that's not possible if the algorithm is tied to a fixed set of types.
ReplyDeleteYes, constraint like this restricts the genericity, but at least, it can be quite useful, for example, I have a large class for integer, then the same long code for uint, for single, for double, etc. Its an horrible redundant unit, but hey ! it works
ReplyDeleteDavid Berneda The point is what happens when I want to use your code with my data type. Done the way you propose, I need you to change your code. Done the way I propose, no such change is needed. The compiler checks that my type has the necessary capabilities and off we go. Of course, with templates it's even easier, but we don't have templates do we.
ReplyDeleteYes much better (more generic) with support for operators. Anyway there are many ocasions you don't need to offer usage outside of your units, just for internal use. About your proposal, if each operator was backed with its own interface (ie: IAddoperator, ISubtractOperator, etc), current generic constraint allowed syntax could fit.
ReplyDeleteDavid Berneda The performance would be dire. For user defined numeric data types, e.g. complex number, you need to use operator overloading on records to have respectable perf.
ReplyDeleteYes I mean syntax sugar, no refcount involved
ReplyDeleteDavid Berneda I think the big perf issue with interfaces is the heap allocation of implementing objects. For small numeric types that is death. But also method dispatch is expensive because of the indirection.
ReplyDeleteAFAIK you could use interfaces with records, and no heap allocation. It is tricky, but has been done for numbers: https://sergworks.wordpress.com/2012/04/01/interfaces-without-objects
ReplyDeleteAnd you do not need interfaces if you use value objects. Copying an integer value would always be faster than allocating a class handling it.
We agree, for sure: sometimes, we just better use the blank compiler with its plain value types, right? ;
A. Bouchez Yes, you can fake out interfaces. But you still have a layer of indirection when invoking methods. And you still have all those AddRef/Release calls. Templates are a massive boon here.
ReplyDeleteDavid Heffernan You are right.
ReplyDeleteEven if I suspect that refcount + indirection layer won't only slightly hurt the performances, unless the method process is almost instant.
Templates are great - and I wonder if Mustache may not just replace for Delphi the T4 engine as commonly used for C#. We used them for some internal and external projects, and having generated units is pretty powerful. And won't mess up the compiler, which remain untouched. It also allows to check the actual code compiled, which is pretty convenient for debugging.
What we like with Mustache is that they are logic-less, so the logic comes from the actual application - even if we recently broke the dogma and added {{#if ...}} blocks in our SynMustache.pas unit.
A. Bouchez Thanks for that comment. I've not heard of Mustache before now. I will take a look.
ReplyDeleteDavid Heffernan take a look at http://synopse.info/files/html/Synopse%20mORMot%20Framework%20SAD%201.18.html#TITL_81
ReplyDelete