Default record fields

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Default record fields

Ryan Joseph
I want to do a pivot away from the macro stuff to ask another question. Since I’ve wanted to contribute to the compiler for so long and I finally have a little understanding I’d like to know if there’s anything minor I could do, that isn’t offensive to the compiler team.

What comes to mind first as being minor (or not, I don’t know) and important are default record fields. Is there are reason this never existed in Pascal? It’s in C++, C#, Swift etc…. and I use it often. The compiler added advanced records but making a static class method which is hidden down in the implementation is annoying boiler plate I’m sick of doing (plus calling it, or forgetting to). The new initialize operator is the best alternative but again it’s boiler plate and adds methods in the implementation.

Is there any reason we can’t do that? Is it a design choice?

type
        TVec2 = record
                x: integer = 0;
                y: integer = 0;
        end;

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Default record fields

Karoly Balogh (Charlie/SGR)
Hi,

On Fri, 22 Jun 2018, Ryan Joseph wrote:

> I want to do a pivot away from the macro stuff to ask another question.
> Since I’ve wanted to contribute to the compiler for so long and I
> finally have a little understanding I’d like to know if there’s anything
> minor I could do, that isn’t offensive to the compiler team.

<rant>It's not about the compiler team. It's about the integrity of a
programming language, which doesn't matter these days a lot, when all
languages turned into a feature race to provide the same broken concepts,
but with slightly different syntax. Nevermind. I sometimes do not even
understand how people did stuff for 50 years without
TObjectClassAdvancedTemplateGenericRecordRTTI...</rant>

> What comes to mind first as being minor (or not, I don’t know) and
> important are default record fields. Is there are reason this never
> existed in Pascal? It’s in C++, C#, Swift etc…. and I use it often.

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))?)

> The compiler added advanced records but making a static class method
> which is hidden down in the implementation is annoying boiler plate I’m
> sick of doing (plus calling it, or forgetting to). The new initialize
> operator is the best alternative but again it’s boiler plate and adds
> methods in the implementation.
>
> Is there any reason we can’t do that? Is it a design choice?

It's a design choice.

In general, could you stop trying turning Pascal into C/C++? What C++
provides is mostly what is provided by advanced records (the useful
subset). Except C++ allows writing the default initializer into the type
declaration which then may or may not get executed, because C++ is a
godforsaken mess.

What you can also do is, to declare the type, then declare a set of
defaults with "const", which you can also write into the interface
section. Then if you need a certain initialization for that type, just do
it with an assignment.

var
  myvar: mytype;

const
  myvardefault: mytype = <initializer>;

begin
  myvar:=myvardefault;
end;

In this case the compiler will even warn you, if you A., forgot to
initialize the variable B., forgot to initialize a field in the
initializer. I'm using similar pattern in my 3D engine, where I have
various set of default vertices and matrices defined as consts, which are
still the same type, and i can initialize them this way to whichever
default I need..

If you need huge amounts of this construct, I would advise you to generate
it as Michael said, which is what you would do with extended preprocessing
or similar syntax sugar, like this one. It's just implicit code
generation.

Charlie
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Default record fields

Joost van der Sluis
On 06/22/2018 01:19 PM, Karoly Balogh (Charlie/SGR) wrote:

> On Fri, 22 Jun 2018, Ryan Joseph wrote:
>
>> I want to do a pivot away from the macro stuff to ask another question.
>> Since I’ve wanted to contribute to the compiler for so long and I
>> finally have a little understanding I’d like to know if there’s anything
>> minor I could do, that isn’t offensive to the compiler team.
>
> <rant>It's not about the compiler team. It's about the integrity of a
> programming language, which doesn't matter these days a lot, when all
> languages turned into a feature race to provide the same broken concepts,
> but with slightly different syntax. Nevermind. I sometimes do not even
> understand how people did stuff for 50 years without
> TObjectClassAdvancedTemplateGenericRecordRTTI...</rant>

I read Ryan's mail as an attempt to get involved in some
compiler-development. And he's wondering what a nice task could be.

Can't we think of something? Maybe he can help with the last parts of
the modules-support from Sven.
Or with the merges of the Attributes branche that I once started.
Although I know that it's high on Sven's todo-list.

Maybe both topics are to difficult. But maybe something else? Some
optimisation?

Regards,

Joost.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Default record fields

Karoly Balogh (Charlie/SGR)
Hi,

On Fri, 22 Jun 2018, Joost van der Sluis wrote:

> >> I want to do a pivot away from the macro stuff to ask another question.
> >> Since I’ve wanted to contribute to the compiler for so long and I
> >> finally have a little understanding I’d like to know if there’s anything
> >> minor I could do, that isn’t offensive to the compiler team.
> >
> > <rant>It's not about the compiler team. It's about the integrity of a
> > programming language, which doesn't matter these days a lot, when all
> > languages turned into a feature race to provide the same broken concepts,
> > but with slightly different syntax. Nevermind. I sometimes do not even
> > understand how people did stuff for 50 years without
> > TObjectClassAdvancedTemplateGenericRecordRTTI...</rant>
>
> I read Ryan's mail as an attempt to get involved in some
> compiler-development. And he's wondering what a nice task could be.
>
> Can't we think of something? Maybe he can help with the last parts of
> the modules-support from Sven.
Well, true. Sorry if I sounded too rude. But both threads he started
sounded a bit like "this is broken in the language, so lets fix it", where
I beg to differ.

There are plenty of things to implement indeed. I think we are mostly
lacking on high-level optimizations, but that's a very tedious job, and
hardly helps the use case Ryan was working on, which seemed to be clearly
his driving force in this.

About the really high level generics, RTTI, & whatever topics I'm probably
not the right person to consult indeed. :)

Charlie
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Default record fields

Ryan Joseph
In reply to this post by Karoly Balogh (Charlie/SGR)


> On Jun 22, 2018, at 6:19 PM, Karoly Balogh (Charlie/SGR) <[hidden email]> 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.


Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Default record fields

Ryan Joseph
In reply to this post by Karoly Balogh (Charlie/SGR)


> On Jun 22, 2018, at 9:12 PM, Karoly Balogh (Charlie/SGR) <[hidden email]> wrote:
>
> Well, true. Sorry if I sounded too rude. But both threads he started
> sounded a bit like "this is broken in the language, so lets fix it", where
> I beg to differ.

I can’t help with higher level stuff because I don’t know how the compiler works well enough. Optimizations as well are way over my head.

I’ve been using Pascal for over 20 years now and in that time the language itself has changed, computers have changed and even I’ve changed. The language isn’t broken but there should be easier ways to accomplish some tasks. I didn’t even think about it until I saw other languages do it better and then wondered why we aren’t doing the same thing.

I didn’t think that was a controversial statement to make. I really thought people wanted macros with parameters and I’m shocked again to find that default record fields may be widely despised also, but that’s why I’m asking.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Default record fields

Ryan Joseph
In reply to this post by Joost van der Sluis


> On Jun 22, 2018, at 8:32 PM, Joost van der Sluis <[hidden email]> wrote:
>
> I read Ryan's mail as an attempt to get involved in some compiler-development. And he's wondering what a nice task could be.

Yes that’s right. I honestly thought default record fields was a requested feature and it’s one I wanted also.

Remember this is all relative to the users. Sven's dynamic array extensions are great but honestly I’d rather have better record init since I do that more often. That doesn’t mean I don’t want dynamic arrays in the language at all.

The biggest item on my wish list is anonymous functions but that’s way over my head. I’d like class helpers to exist in multiple scopes at once but I’m pretty sure I couldn’t do that either, or I’d give up before it was finished.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Default record fields

Anthony Walter-3
Ryan,

We all desperately want dynamic packages completed. Perhaps you might have some interest in that?

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Default record fields

Ryan Joseph


> On Jun 22, 2018, at 9:43 PM, Anthony Walter <[hidden email]> wrote:
>
> Ryan,
>
> We all desperately want dynamic packages completed. Perhaps you might have some interest in that?

I never heard of "dynamic packages" before so that’s not a good start. :) What is it?

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Default record fields

Anthony Walter-3
They are the same as Free Pascal packages, that is a collection of units which can be compiled separately, but with the added ability to be loaded and unloaded after a program has started. Presumably there also exists some dynamic package utility functions built into the system unit that also allow users to search through a package and find units, variables, functions, and types found in the package, then bind to these things while the program is running.

Example usage of this would be to allow components to be installed inside the Lazarus IDE without the need to rebuild the IDE. Also, users can design programs that allow for plugins in the form of dynamic packages. Finally, a possibility also would exist to write a package browser that could examine packages and tell you what's in them without having to parse source code. 

I'm sure there's more that can be done with dynamic packages, but I think you get the idea.

Sven says dynamic packages are coming, but a few independent things need to be completed. Sven, do you care to add anything?

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Default record fields

Ryan Joseph


> On Jun 22, 2018, at 10:08 PM, Anthony Walter <[hidden email]> wrote:
>
> I'm sure there's more that can be done with dynamic packages, but I think you get the idea.
>

I’m not a Lazarus user so this is probably not a good fit for me. I’ve never encountered anything like a “package" in FPC so there would be a pretty steep learning curve just trying to understand the system in which they exist. They should like dynamically linked libraries but clearly they’re something different.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Default record fields

Ralf Quint
In reply to this post by Karoly Balogh (Charlie/SGR)
On 6/22/2018 4:19 AM, Karoly Balogh (Charlie/SGR) wrote:

> Hi,
>
> On Fri, 22 Jun 2018, Ryan Joseph wrote:
>
>> I want to do a pivot away from the macro stuff to ask another question.
>> Since I’ve wanted to contribute to the compiler for so long and I
>> finally have a little understanding I’d like to know if there’s anything
>> minor I could do, that isn’t offensive to the compiler team.
> <rant>It's not about the compiler team. It's about the integrity of a
> programming language, which doesn't matter these days a lot, when all
> languages turned into a feature race to provide the same broken concepts,
> but with slightly different syntax. Nevermind. I sometimes do not even
> understand how people did stuff for 50 years without
> TObjectClassAdvancedTemplateGenericRecordRTTI...</rant>
+1
It's not (only/just) what "the compiler team" wants. There are people
actually using the compiler. For real life purposes.
And a lot of what people are proposing, over and over again, are
solutions for problems that nobody has (in real life)...

Ralf

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Default record fields

Marcos Douglas B. Santos
On Fri, Jun 22, 2018 at 12:59 PM, Ralf Quint <[hidden email]> wrote:

> On 6/22/2018 4:19 AM, Karoly Balogh (Charlie/SGR) wrote:
>>
>> Hi,
>>
>> On Fri, 22 Jun 2018, Ryan Joseph wrote:
>>
>>> I want to do a pivot away from the macro stuff to ask another question.
>>> Since I’ve wanted to contribute to the compiler for so long and I
>>> finally have a little understanding I’d like to know if there’s anything
>>> minor I could do, that isn’t offensive to the compiler team.
>>
>> <rant>It's not about the compiler team. It's about the integrity of a
>> programming language, which doesn't matter these days a lot, when all
>> languages turned into a feature race to provide the same broken concepts,
>> but with slightly different syntax. Nevermind. I sometimes do not even
>> understand how people did stuff for 50 years without
>> TObjectClassAdvancedTemplateGenericRecordRTTI...</rant>
>
> +1
> It's not (only/just) what "the compiler team" wants. There are people
> actually using the compiler. For real life purposes.
> And a lot of what people are proposing, over and over again, are solutions
> for problems that nobody has (in real life)...

+1
It is better to have a simple language with packages/libs to do the (real) job
than a complex language that try doing anything that someone could
imagine or want to do.

Best regards,
Marcos Douglas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Default record fields

Rainer Stratmann
Am Freitag, 22. Juni 2018, 16:03:28 schrieb Marcos Douglas B. Santos:

> On Fri, Jun 22, 2018 at 12:59 PM, Ralf Quint <[hidden email]> wrote:
> > On 6/22/2018 4:19 AM, Karoly Balogh (Charlie/SGR) wrote:
> >> Hi,
> >>
> >> On Fri, 22 Jun 2018, Ryan Joseph wrote:
> >>> I want to do a pivot away from the macro stuff to ask another question.
> >>> Since I’ve wanted to contribute to the compiler for so long and I
> >>> finally have a little understanding I’d like to know if there’s anything
> >>> minor I could do, that isn’t offensive to the compiler team.
> >>
> >> <rant>It's not about the compiler team. It's about the integrity of a
> >> programming language, which doesn't matter these days a lot, when all
> >> languages turned into a feature race to provide the same broken concepts,
> >> but with slightly different syntax. Nevermind. I sometimes do not even
> >> understand how people did stuff for 50 years without
> >> TObjectClassAdvancedTemplateGenericRecordRTTI...</rant>
> >
> > +1
> > It's not (only/just) what "the compiler team" wants. There are people
> > actually using the compiler. For real life purposes.
> > And a lot of what people are proposing, over and over again, are solutions
> > for problems that nobody has (in real life)...
>
> +1
> It is better to have a simple language with packages/libs to do the (real)
> job than a complex language that try doing anything that someone could
> imagine or want to do.
>
Yes, you can already do almost everything you want with freepascal.
Keep it easy.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Default record fields

Jim Lee
In reply to this post by Karoly Balogh (Charlie/SGR)


On 06/22/2018 04:19 AM, Karoly Balogh (Charlie/SGR) wrote:
>
> <rant>It's not about the compiler team. It's about the integrity of a
> programming language, which doesn't matter these days a lot, when all
> languages turned into a feature race to provide the same broken concepts,
> but with slightly different syntax. Nevermind. I sometimes do not even
> understand how people did stuff for 50 years without
> TObjectClassAdvancedTemplateGenericRecordRTTI...</rant>
>

Restraint is a virtue exercised by the wise and experienced; the young
and foolish prefer abandon.

-Jim
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Default record fields

Free Pascal - General mailing list
In reply to this post by Anthony Walter-3
Am 22.06.2018 um 17:08 schrieb Anthony Walter:
> Sven says dynamic packages are coming, but a few independent things
> need to be completed. Sven, do you care to add anything?
It's mainly low level code generation and integration with the RTL, so I
doubt that there is much that can be helped there.

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Default record fields

Free Pascal - General mailing list
In reply to this post by Ryan Joseph
Am 22.06.2018 um 16:18 schrieb Ryan Joseph:

>
>> On Jun 22, 2018, at 6:19 PM, Karoly Balogh (Charlie/SGR) <[hidden email]> 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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Default record fields

Ryan Joseph


> On Jun 23, 2018, at 3:15 AM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>
> 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.

Sure, and those are all welcome additions to the language which I use often.

I’m speaking of the general friction when creating custom records and having to go through the boiler plate of adding those methods every time and breaking the record into the implementation so I can have class functions (which need to be called also) or now initialize operators which save the calling step. It’s just friction in the development process and busy work.

My thinking was that because variables can assign values at declaration it would be reasonable to assume that record fields could have default values which would be assigned at declaration. It sounds like a natural extension of the syntax that already exists.

I assumed (wrongly perhaps) because this feature exists in c++, c#, swift etc… that it was in demand.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Default record fields

Free Pascal - General mailing list
> My thinking was that because variables can assign values at declaration it
would be reasonable to assume that record fields could have default values
which would be assigned at declaration. It sounds like a natural extension
of the syntax that already exists.

Those are two different things actually: Declaration time initialization for
variables vs default record field values. The former doesn't cause confusion
because the value and the variable are in the same place, but the latter
does, as Sven said: "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."

Now suppose you have that feature a record type T in unit A, then a code
somewhere that uses unit A has a variable V of type T declared. How could
you be sure what value that V holds? At best you have to initialize it right
there anyway, making the default value useless. Certainly don't imagine
you're the writer of unit A who knows that T has some default values. Other
languages POV are mostly simply ease of typing, they don't think the
consequences this far.



--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Default record fields

Ryan Joseph


> On Jun 23, 2018, at 3:09 PM, leledumbo via fpc-pascal <[hidden email]> wrote:
>
> Those are two different things actually: Declaration time initialization for
> variables vs default record field values. The former doesn't cause confusion
> because the value and the variable are in the same place, but the latter
> does, as Sven said: "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.”

Why would you be confused if a record set a default state? If you don’t know the fields in your record you’re in trouble anyways because you don’t know the state of your program.

var
  r: TVec2;
begin
  // the record is either A) garbage or B) a default value.
  // if you can’t remember the default values you set then
  // by all means do r := TVec2.Zero every time. Have fun
  // making class procedure Zero; methods for all your custom methods also

or just force default init with a keyword;

var
  r: TVec2; default;
begin
  // now I know r = {0,0} because I set those values


….

type
        TVec2 = record
                x: integer = 0;
                y: integer = 0;
        end;

>
> Now suppose you have that feature a record type T in unit A, then a code
> somewhere that uses unit A has a variable V of type T declared. How could
> you be sure what value that V holds? At best you have to initialize it right
> there anyway, making the default value useless. Certainly don't imagine
> you're the writer of unit A who knows that T has some default values. Other
> languages POV are mostly simply ease of typing, they don't think the
> consequences this far.

Because Pascal doesn’t init by default you would be effectively overriding that behavior by adding default fields. In worst case scenario you’re still in the same place as before, i.e. you don’t know what the state is of your data. The programmer needs to know what they’re doing and what the contents of their data is regardless. Pascal's default behavior is “do noting” and default fields would just override that.

Swift FORCES the init of structures because they follow your general line of thinking which is “programers don’t know what the contents of their data are, so the language needs to guarantee a default state for them”. I hate that about Swift because it hold your hands at all times and adds enormous amounts of friction into the process. No fun at all.

Now in 3.1.1 we can use init operators to guarantee records are in a default state upon use. This is great but they add extra boiler plate code in the implementation section.

type
        TVec2 = record
                x, y: integer;
                class operator Initialize(var rec: TVec2);
        end;


class operator TVec2.Initialize(var rec: TVec2);
begin
        rec.x := 0;
        rec.y := 0;
end;


Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal