Should my record be a class instead?

[Mike Torrettinni 198]

4 hours ago, David Heffernan said:

You claim that these global variables "need to be global". Why is that? It would not surprise me if it turned out not to be the case. 

That record is part of a feature (report) that needs to be available with and without Main form, so application can have a user interface or not. It is standalone report, so I set it as global to be able to connect controls' when needed or just being run from global method that runs all needed reports in case project is run without interface.

If it was just a subset of another feature, then I can see why it can be non-global record, but it is a feature on it's own with a good number of lines of code and form controls use it's methods, so I think it should be global.

 

Please understand from my point I'm starting from everything is global, now going to have a global record (or class) with all local methods and vars, while before everything was global. Now I have 1 record a few public methods and a lot of local definitions. that hopefully don't mess with Error insight and Code completion in Main form or any other unit.

 

Up until a few days ago I didn't know that Record can have Private definitions, which is one of the reasons for this question... if I move all local definitions from implementation to Record Private section, should it then be a class.

No, unless I need a class behavior. Or the other way around, when I completely switch to class based (OOP) principles, this question is not applicable.

 

 

[David Heffernan 2345]

9 hours ago, Mike Torrettinni said:

That record is part of a feature (report) that needs to be available with and without Main form, so application can have a user interface or not. It is standalone report, so I set it as global to be able to connect controls' when needed or just being run from global method that runs all needed reports in case project is run without interface.

If it was just a subset of another feature, then I can see why it can be non-global record, but it is a feature on it's own with a good number of lines of code and form controls use it's methods, so I think it should be global.

 

Please understand from my point I'm starting from everything is global, now going to have a global record (or class) with all local methods and vars, while before everything was global. Now I have 1 record a few public methods and a lot of local definitions. that hopefully don't mess with Error insight and Code completion in Main form or any other unit.

 

Up until a few days ago I didn't know that Record can have Private definitions, which is one of the reasons for this question... if I move all local definitions from implementation to Record Private section, should it then be a class.

No, unless I need a class behavior. Or the other way around, when I completely switch to class based (OOP) principles, this question is not applicable.

 

 

Nothing in that that suggests there is a need for a global variable. 

[Rudy Velthuis 91]

On 2/5/2019 at 11:13 PM, David Schwartz said:

When you pass everything as a string, as this guy seemed to be doing, you probably do. Or you need lots of exception handling code to deal with conversion errors.

Yes, that may be. I actually declare parameters as the type that is needed, and not everything as string.

[Rudy Velthuis 91]

On 2/1/2019 at 4:15 AM, FredS said:

At that point just change to a class.

Why?

 

On 2/6/2019 at 10:00 AM, Sherlock said:

Only safe if it works...and just to make sure, this is still Delphi we are talking about, correct? So this feature might work reliably two versions after the introduction, if it gets used enough for a decent flow of error tickets from the get go. At the current rate for RIO, people (including me) seem to be holding off the upgrade until RIO.1 is out - the more people do that, the less likely that .1 will make sense. Sorry for that OT interjection there...carry on.

We are talking about Delphi, and I am of course assuming that, whatever it is that takes the boring and tedious and often failing manual tasks off my hands, works. Nothing is safe if it doesn't, not even a memory manager for manual management. (Sheesh!)

[FredS 138]

8 hours ago, Rudy Velthuis said:

On 1/31/2019 at 7:15 PM, FredS said:

At that point just change to a class.

Why? 

To use the Class Destructor for cleanup.

[Rudy Velthuis 91]

18 minutes ago, FredS said:

To use the Class Destructor for cleanup.

A record type can have a class destructor too. A record type just can't have a normal destructor yet.

Edited February 7, 2019 by Rudy Velthuis

[FredS 138]

1 hour ago, Rudy Velthuis said:

A record type can have a class destructor too. A record type just can't have a normal destructor yet.

Oh boy..

 

It can't in MMX up to14.0.5 🙂

 

 

 

[Rollo62 536]

Record destructors are a brand new feature sind 10.3 Rio.

Do you really want to use it already ?

http://blog.marcocantu.com/blog/2018-november-custom-managed-records-delphi.html

http://docwiki.embarcadero.com/RADStudio/Rio/en/New_features_and_customer_reported_issues_fixed_in_RAD_Studio_10.3

Edited February 8, 2019 by Rollo62

[FredS 138]

4 hours ago, Rollo62 said:

Record destructors are a brand new feature sind 10.3 Rio.

 

This was about Record class destructors.

[David Schwartz 426]

12 minutes ago, FredS said:

 

This was about Record class destructors.

records and classes are different. Classes already have destructors.

[Rudy Velthuis 91]

7 hours ago, Rollo62 said:

Record destructors are a brand new feature sind 10.3 Rio.

Do you really want to use it already ?

http://blog.marcocantu.com/blog/2018-november-custom-managed-records-delphi.html

http://docwiki.embarcadero.com/RADStudio/Rio/en/New_features_and_customer_reported_issues_fixed_in_RAD_Studio_10.3

That feature (managed records, i.e. records with default constructors, copy constructors, conversion constructors, overloaded assigment operators and destructors) was postponed, actually. Currently, records cannot have destructors, not even in Rio.

 

But I was talking about class destructors, not the normal instance destructors. Records cannot have destructors (yet), but they can have class destructors, even in much older versions (IIRC, since XE2, but I may be wrong about the version).

Edited February 8, 2019 by Rudy Velthuis

[Rudy Velthuis 91]

2 hours ago, David Schwartz said:

records and classes are different. Classes already have destructors.

And records have class constructors and class destructors too.

 

You seem to be confusing class destructors with destructors. Records cannot have destructors, but they can have class destructors. These are not the same thing. See the link I posted in another reply.

[David Schwartz 426]

11 minutes ago, Rudy Velthuis said:

And records have class constructors and class destructors too.

 

You seem to be confusing class destructors with destructors. Records cannot have destructors, but they can have class destructors. These are not the same thing. See the link I posted in another reply.

Gotcha. My mistake.

[Rudy Velthuis 91]

21 hours ago, FredS said:

Oh boy..

 

It can't in MMX up to14.0.5 🙂

 

 

 

MMX doesn't define the language. And records can only have static class methods anyway.