Thanks, logged as bugs://85362 (subclassing records)
1 Like
Note that 1 thing will not work when it comes to records:
- Virtual/override. There is no real VMT to speak of, so virtual calls don’t work.
When it comes to interfaces you can always reimplement them of course.
So considering this:
type
TPoint = record
public
x,y : float;
method Multiply(const point: TPoint) : TPoint; virtual;
begin
//proper calculation here...
end;
end;
TMyDifferentPoint = record(TPoint)
public
method Multiply(const point: TPoint) : TPoint; virtual; override;
begin
//wont work?
end;
end;
So the user then needs to replace this with an Interface, lets call it IPointOperations which then has the “Multiply, Add, Subtract” etc…
but im actually curiours, how does the freepascal compiler handle their old-style-objects then, since they can do abstract and virtual stuff but do not allow on the other hand for interfaces haha, can you help me understanding those differents, aswell as for here, I ask out of cluelessness 
Old style objects actually have a VMT; they’re also meant to be called virtually. They also have a vmt pointer at the start iirc.
Lol, but why then they cannot implement interfaces, interfaces require a VMT aswell, dont they?
Interfaces were introduced long after objects, and really were only done (in Delphi) to support COM initially. They are only supported on classes.
ahh yea I remember, so completly different architecture. Dont worry, I can replace then the override stuff with proper interfaces, and handle it like that, to replace the virtual stuff. Actually if you say that they do not have a VMT, it think makes records more lightweight then, do they?
Oke so it’s not entirely true they don’t have a vmt. They have one to support interfaces of course. What they’re missing is what classes have at [0], which is a pointer to that same VMT. Records are always purely the data they define, while classes/objects also have a vmt pointer.
Depends how much of a complexity this would be for you, but another point popped in my mind, since records then are not able to allow for overrides/Virtual methods, would it not be then possible to overcome the “Diamond Problem” C++ has with Muitiple Inheritance? Since this only arises when dealing on subclasses overrding the virtual stuff.
And for the usecase, it would just be more flexiable, again not smth REALLY must have but could allow for abit easier records inheritance-models since u do not have this diamond problem to face with,.
iirc the diamond problem is also when subclassing the same tree, through different paths.
ie:
a has int X;
b and c descend from a.
d descends from b and c, now has two 'X’s.
true but this could fell away I think if you just ignore one of the values, and so to speak say (yea I know it has both, but its duplicated, since its duplicated, we can simply reducec it to one field/property, whatever)
Like we ignore the fact it has 2 or even more “int X” fields, and we take only the one from the root, lets say.
The only reason I came up with this now is since records are way more lightweight than classes due to their memory-layout and location(stack) the MultiInheritance should not cause memoryissues (this is in C++ always to be carefully thoughtout since they are mostly used for large heapallocs (ateast in the contexts I have witnessed) and 2. they do not deal with the virtual/abstract problems you usually have with multi-class-inheritance, so its something you may take into consideration, but again, its just brainstorming, not something I would die for to have it haha
I have an almost working version of struct subclassing with interface support.
1 Like
xD not bad my friend, I knew that you guys know what you are doing butt not in that pace haha 
It’s done. The next build has this feature. (The issue will stay open till it’s documented)
1 Like
Carlo I have to appologize, i was abit to quick on this one here:
It should leave the source intact, (aInput in this case) since it must destroy the resources it points to first then gets destroyed (maybe read this article here: I didnt perfectly explained it, my bad,… c++ - What is move semantics? - Stack Overflow (especially the accepted answer!)
but I think in C++ it is that the temporary object is being destroyed immediately after the line reaches the “;” idk if this is the case for island/cocoa compiler too, if this is the case, better do not discard the “aInput” directly, since it may cause a crash, when it sees that the value was nil b4 and then tries to destroy itt again, idk now …
but maybe just do in the move-ctor: this
constructor Move(var aInput: ^InputType);
begin
self.data := aInput^.Data; //the pointer to some heapallocateed stuff
aInput^.Data := nil;
aInput := nil; //this line im not sure, sicnce in C++ that guy from forum said this is wrong behaviour, maybe here not?
end;
Ah so it’s still “valid” (as in, the finalizer will still get called), but the compiler knows it’s the "last’ use of the value.
yea i think this is how it would be! Wasnt quiet sure on that myself^^
Im wondering tho, why would a, if u want to call it like that, safe extra “aInput := nil” cause a crash, the compiler in that case would just skip the line if he sees no use for it, or am I wrong? Since its about to be destroyed anyway?
I’m going to see if I can easily catch this situation (but not today), and what semantics I’ll end up with.
Dw mate, Take your time for this, this maybe need to be carefully thought more precise so no hurry, im thankful you guys are considering such stuff anyway, this makes me more motivated to use it (which obvuiously doesnt mean to accept every crap of a feature)
But I was sure on the record inhertance and movesemantics, that they will enhance Islands power in a lot of cases, when you need to be less memory hungry, call it like this haha.
All in all, have a good rest mate and I will check your reply on the headerimporter in a minute, since you are correct, i messed around with the targets, thx for the hint!
ah and btw, if you need more insight for this move-stuff, i wanna suggest really you to have a closer look into his answer, it was really well formulated out to grasp the idea of move-ctor/semantics!