Jump to content
Mike Torrettinni

Should my record be a class instead?

Recommended Posts

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.

 

 

Share this post


Link to post
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. 

Share this post


Link to post
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.

Share this post


Link to post
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!)

Share this post


Link to post
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.

Share this post


Link to post
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 by Rudy Velthuis

Share this post


Link to post
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 🙂

 

 

 

mmx.png

Share this post


Link to post
4 hours ago, Rollo62 said:

Record destructors are a brand new feature sind 10.3 Rio.

 

This was about Record class destructors.

Share this post


Link to post
12 minutes ago, FredS said:

 

This was about Record class destructors.

records and classes are different. Classes already have destructors.

Share this post


Link to post
7 hours ago, Rollo62 said:

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 by Rudy Velthuis

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
21 hours ago, FredS said:

Oh boy..

 

It can't in MMX up to14.0.5 🙂

 

 

 

mmx.png

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

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×