What is the difference between the new ADVANCED RECORD and the old OBJECT?

[malcome]

What is the difference between the new ADVANCED RECORD and the old OBJECT?

Code: Pascal  [Select][+][-]

1.  
2. {$mode objfpc}{$H+}
3. {$modeswitch ADVANCEDRECORDS}
4.  
5. type
6.   TOld = object
7.   private
8.     function getheight: integer;
9.     procedure setheight(AValue: integer);
10.   public
11.     property Height: integer read getheight write setheight;
12.   end;
13.  
14.   TNew = record
15.   private
16.     function getheight: integer;
17.     procedure setheight(AValue: integer);
18.   public
19.     property Height: integer read getheight write setheight;
20.   end;
21.  
22. var
23.   Fnew: TNew;
24.   Fold: TOld;
25.  
26. begin
27.   Fnew.Height := 100;
28.   Fold.Height := 200;
29.   writeln(Fnew.Height);
30.   writeln(Fold.Height);
31. end.
32.  
33.  

Thank you.

[balazsszekely]

@malcome

Try to inherit something from TOld then from TNew and you'll see the difference.

[malcome]

Hi GetMem.
Only that? IMHO,it is atrophy.

[marcov]

Make a method virtual in the object case, and compare the sizeofs()

[Graeme]

What is the difference between the new ADVANCED RECORD and the old OBJECT?

Delphi broke OBJECT support and reinvented the wheel a couple years later with "advanced records".  In FPC  you require an extra compiler mode to enable advanced records.

FPC has never broken OBJECT's, and they are the precursor to CLASS. I like them and use them often. I may be old school (from my TP days), but for me a RECORD is a structure without methods, so that's why I don't use Advanced Records in any of my code.

In the end I guess they do the same thing though.

[mdbs99]

And after almost 3 years, are there real difference to justify advanced records or it is just to follow Delphi?

Thanks.

[marcov]

And after almost 3 years, are there real difference to justify advanced records or it is just to follow Delphi?

IMHO people glorify the old object for no good reason.

[Awkward]

I using old objects in some places. Not because they have New/Dispose extensions but for object inheritances

[lucamar]

And after almost 3 years, are there real difference to justify advanced records or it is just to follow Delphi?

Following Delphi has its merits, if not done blindly; after all, Delphi is the "leader" in Pascal programming and lots (most?) of new Pascal code is written using their extensions.

With respect to advanced records, old-style objects and classes ... well, they can be seen as gradations of a concept: in the lower level advanced records, a little beyond that old-style objects and last the more powerful classes. And while it is true that adv. records and old-style objects differ only a little---basically, beyond implementation details, in inheritance capability---they still differ enough that an election has to be made between using one or the other type ... or jump directly to a class.

IMHO people glorify the old object for no good reason.

I don't think "glorify" is the adequate word here. There are times---not many, granted---when one needs something more than records but a class is, somehow, overkill. In that middle ground is where the object type fits.

That is, unless records keep "advancing" and become objects 

[mdbs99]

IMHO people glorify the old object for no good reason.

I have no feelings about that. I want to move on, using what programmers might use nowadays, but I'm not sure if the object type is deprecated of not. IIRC, Delphi says yes, it's deprecated. However, as have already pointed here, object type is different to advanced records...

So, nowadays, why should I choose advanced records instead of object type?
(the answer should not only consider that Delphi deprecated object but, instead, explain the technical reasons)

regards,

[Thaddy]

IMHO people glorify the old object for no good reason.

I have no feelings about that. I want to move on, using what programmers might use nowadays, but I'm not sure if the object type is deprecated of not. IIRC, Delphi says yes, it's deprecated. However, as have already pointed here,

No good reason until -
- advanced records showed up.
- there is still stack vs heap.
Nowadays I don't take notice of it unless I absolutely need performance (read below: these days are gone) and objects are still the better option there.
Funny thing is that features of advanced records are bolted on old school objects... something I don't think is a particularly wise decision...

Hey, if you want managed types use C#? (Utter respect in most language decisions but some are rubbish).

[marcov]

Well, inheritance is a point. In theory you could also have static base "objects" deep in your framework, and later derive real objects (as in capable of polymorphism) deeper.

On the flip side however, for those mostly shallow advantages, you would be stuck with a 1990 era object model, manually declaring pointers to objects forever etc etc. It is just not worth it.

To main tp object, let alone if one would have to implement it from scratch.

And I'm someone with considerable tp object experience in FPC due to bugfixing the IDE and having done FPC OO before it had classes.

p.s. I don't buy the performance argument at all, since that can be done with advanced records as well. Even before advanced records I used records for that with procedures operating on them. I don't see the reason to have yet another structured type for that.

[Thaddy]

p.s. I don't buy the performance argument at all, since that can be done with advanced records as well. Even before advanced records I used records for that with procedures operating on them. I don't see the reason to have yet another structured type for that.

If you read carefully I made the point it used to be the case.... Advanced records changed that a bit.
The strongest use-case is still probably KOL over the past 18 years..(Not only for Windows, but as a framework paradigm)

[mse]

Do advanced records support inheritance? AFAIK no.
One often has different records with a common header. Here base objects which will be inherited by specialized objects are convenient. For many cases classes (TObject descendants) have too much not needed overhead so "old style" objects fit well.

In MSElang "object" and "class" are almost the same. "class" instances are always allocated on heap and provide implicit pointer dereference. "object" is  instantiated as stack- or global-variable or on heap if the "object" has a constructor and a destructor, see
https://gitlab.com/mseide-msegui/mselang/wikis/home/mselang_objects
MSElang objects and classes can have variant parts, classes can inherit from objects.

[marcov]

Do advanced records support inheritance? AFAIK no.

That's what I said. And also you can't derive classes from advanced records. Those are the minor advantages, but I consider them largely theoretical.

One often has different records with a common header.
Here base objects which will be inherited by specialized objects are convenient. For many cases classes (TObject descendants) have too much not needed overhead so "old style" objects fit well.

Yeah, or just read the general header and a separate header for the extensions. These (doutbful!) cornercases are not really motivations IMHO to keep a complete object model running.

In MSElang "object" and "class" are almost the same. "class" instances are always allocated on heap and provide implicit pointer dereference. "object" is  instantiated as stack- or global-variable or on heap if the "object" has a constructor and a destructor, see
https://gitlab.com/mseide-msegui/mselang/wikis/home/mselang_objects
MSElang objects and classes can have variant parts, classes can inherit from objects.

If I would start over, that's probably what I would do, with one exception. I would leave objects pure structures, so no VMT (and thus probably no virtual).

One of the things I hate most about TP objects, is that you can't immediately see if it is a pure record or an object.