[fpc-pascal] Default record fields

[Sven Barth]

Am 22.06.2018 um 16:18 schrieb Ryan Joseph:
>
>> On Jun 22, 2018, at 6:19 PM, Karoly Balogh (Charlie/SGR) <charlie at scenergy.dfmk.hu> wrote:
>>
>> Because C# and Shift are managed languages, and C++ just includes
>> everything for no good reason. And this is actually major, with far
>> fetching implications. C++ is an utter mess for this, with the default
>> initializer sometimes called and sometimes not, when you declare a
>> variable of this type. Because if you pull the way computers work into the
>> equation, it complicates things a lot. It matters where you define a
>> variable of this type. On the heap, on the stack or on the global variable
>> list, you have to compile different code for this, and you are probably
>> won't be able to cover all corner cases. (Eg. what if you allocate this
>> type with GetMem(sizeof(type))?)
> I just want practical solutions to the problems I face daily. Making boiler plate constructors to initialize records is one of them. Maybe designing a programming paradigm and strictly adhering to it is works for you but I want to make my life easier and enjoy programming as much as I can.
>
> Seriously though why shouldn’t init'ing records be easier? Do people like making constructors all the time and scrolling around to find them? I don’t know about the implications of the idea but if it’s too insanely complicated to manage then obviously it’s not worth it.
More often than not people use classes instead of records and even then 
for records constructors (or factory methods) cover the important cases. 
E.g. for TPoint there is Point() while 3.0.0 also added TPoint.Create() 
and a TPoint.Zero() as convenience method for an empty TPoint.

Also using an IDE like Lazarus it's easy to see the methods of a TPoint 
by typing "SomePointVar.|" and pressing Ctrl + Space. On the other hand 
to know whether the fields are initialized or not you'd need to navigate 
to the type which means leaving your current zone of development.

Regards,
Sven