As mentioned in the title pls have a deep look into all the little examples I made for the Record-inheritance stuff in the .zip, i was very descriptive imho what is related to that, and I have some questions which I would like to get solved, in order for me to understand fully how they work.
Thanks!
ConsoleApplication4.zip (1.2 MB)
method DoSmthNasty(const a: Integer); {
Im wondering why does the constt "a" parameter in this case hide
the field "a" of TBase. "a" as param should be local to the compiler and hence not collide with alrady existing members?
}
right. this is a standard Oxygene warning. if a parameter has the same name as the class member, that parameter will hide the member that method, hence the warning.
Ok thx for the clarification.
to this, Just for clearer view, could u name what exactly was logged in short phrases.
I would also like to add (since I forgot) that records still in .2591 cant be marked as sealed, compiler doesnt allow this flag on them but makes sense now due to inheritance.
Also (even I have wirtten that down in the project as a comment) Im abit confused how the compiler handles this : consider this code:
bigger.TakeBase(@bigger);
method TakeBase(const base: ^TFirst);
begin
writeLn(base^.a);
end;
bigger.TakeBase(@bigger); ---> calls still its base and not bigger's one
//This will be weird right now how it is, since if both base and its desendant have a member called “a” (afaik the entire declaration must match, so same name and same datatype) and you want a polymorphic behaviour, the compiler will always (currently atleast) use the base.a, and ignores the parameter, even if its a inherited type, he still insists on calling base.a , and not desendant.a, (if desendant is passed ofc!°)
BTW: If the desendant classes do NOT have same memebers, the polymorphy works perfectly fine, he only struggles ofc with same names, I mean yes, you could say to mostly try and avoid using same names but since carlo made that possible it can be considered to do so, and if you consider applying this to your codebase*(using same name over multiple desendants from base)* then there must be also a workaround with the above mentioned problem when using a member which is existent in all classes but compiler ONLY takes always the base one when used as param in a method!
All the items in your project… 
Records don’t have polymorphism (virtual/override).
well I mostly asked that because I was confused of this sentence here from you b4:
The some irritated me in that sense that it sound for me like not everything I mentioned as “bug” or currently not-working is logged, so, yea, only some of those but apparently you logged all what I claimed to be as not “production-ready-yet”?
This was my bad calling it like that, you right, im not speaking so to say, of that polymorphism, but a pseudo variance of that, where you could “polymorphically” access a records member from any input, who is a Desendant of Base AND has that field.
So when calling: “bigger.TakeBigger(<here_anytype_who_inherits_from_base_can_be_placed>” and as I said, it really does it, already but names cannot be equal from base and desendant records, so the polymorphy in that sense works only if you put Base as parameter, and access a field ONLY base has, and now you can pass any desendant of base and the proper field will be called, if it is not included once again! Like if Base has (a, b) and TSub has (c) then you can access in that function TSub.a polymorphically, which is nice. Only the way when the names collide do4esnt work, I dont know what Carlo would say to that, im confused myself with that case tbf.