Record with methods?

[idog]

Classes, TP objects, records with methods... why not complicate the hell out of our programming habits? [...] I think the classes concept is clear enough to avoid any confusion and implementing more "exotic" stuff for the sake of compatibility

IMO, the advantage of Record methods has nothing to do with Delphi compatibility per se or with program performance - it's simply an intuitive, clear and easy way to program. Same reasoning as why I prefer, say, Pascal syntax to C++ syntax  

[Edit] I must add that my experience with this was rather limited, because I quickly found out that in my Turbo Delphi 2006 Explorer, using record methods on records that are function results caused a nasty compiler error due to a bug!

[Martin_fr]

type
  TRecWithMetods = object
    FValue: Integer;
    procedure Foo;
  end;

Behaves exactly like a record. You do *NOT* need to care about freeing any memory. You do neither need to create it, nor destroy it.

And what does "but only within the scope of one procedure" mean?
The above can be used as a function result or var-parameter too.

It can be a field in a class, or in *another* object.

Of course like a record, they can not be circular. A record can not contain a field of it's own type. neither can an "object".

Note that a danger of using TP objects instead of records with methods is that TP objects are not safe with automated types (ansistrings, dynamic arrays). So I wouldn't recommend this.

Is that limitation documented? Never knew about it.

[marcov]

Note that a danger of using TP objects instead of records with methods is that TP objects are not safe with automated types (ansistrings, dynamic arrays). So I wouldn't recommend this.

Is that limitation documented? Never knew about it.

Neither did I. I ran on stackoverflow, and did execute the test I found there with FPC. Bug compatible.

Jonas did own tests, and objects that are dynamically created (new(pobject) ) are safe according to him. (and indeed the test I found used objects statically)

[Martin_fr]

Neither did I. I ran on stackoverflow, and did execute the test I found there with FPC. Bug compatible.

Jonas did own tests, and objects that are dynamically created (new(pobject) ) are safe according to him. (and indeed the test I found used objects statically)

Is there a bug report? or did Jonas say it wouldn't be fixed? I had another bug with objects, and that got fixed => so apparently objects seem to be still supported?

[Zaher]

I (and I think Zaher too) didn't mean "an object" (as in an instance of a class) but "the Object type" (as in "type TMyObj = Object ... end; "). It's probably not a recommended programming tool anymore, but it's closer to Delphi's "Record with methods" than classes, no?

In fact i meant the both Object and Classes the both way give us the needs from "Record with methods", so no need to add this feature for me, i am dreaming about managed objects.

[Troodon]

Man, let's open up two new forum sections, one on algorithms and another one on data structures. Maybe that will keep us from fretting the small things. But that would be more related to FreePascal than to Lazarus, I guess...

[idog]

Man, let's open up two new forum sections, one on algorithms and another one on data structures

http://en.wikipedia.org/wiki/Algorithms_%2B_Data_Structures_%3D_Programs
Sorry, couldn't resist 

In fact i meant the both Object and Classes the both way give us the needs from "Record with methods", so no need to add this feature for me, i am dreaming about managed objects.

I'm not even sure what managed objects are (is it related to databases? I'm not very familiar with database programming)... anyway, as I said somewhere here, Record methods are simply a convenience, and they don't have the overhead of classes. Objects would do the trick if they handled automated types. Now I'm curious to see what will happen, regarding Martin_fr's post.

[marcov]

Neither did I. I ran on stackoverflow, and did execute the test I found there with FPC. Bug compatible.

 Jonas did own tests, and objects that are dynamically created (new(pobject) ) are safe according to him. (and indeed the test I found used objects statically)

Is there a bug report? or did Jonas say it wouldn't be fixed? I had another bug with objects, and that got fixed => so apparently objects seem to be still supported?

The above discussion was part of an indirectly related bugreport: http://bugs.freepascal.org/view.php?id=6545

[Ñuño_Martínez]

type
  TRecWithMetods = object
    FValue: Integer;
    procedure Foo;
  end;

Behaves exactly like a record. You do *NOT* need to care about freeing any memory. You do neither need to create it, nor destroy it.

And what does "but only within the scope of one procedure" mean?
The above can be used as a function result or var-parameter too.

It can be a field in a class, or in *another* object.

Of course like a record, they can not be circular. A record can not contain a field of it's own type. neither can an "object".

You're proposing the C++ object model, aren't you? I don't recommend it. C++ object model is horrible (actually it mix two different object models) and is one of the things I promised myself I will never use C++ again in my life. IMHO the object model used by FPC is one of the best ones (a similar one is used by Objective C, Java, etc.). I can't see true benefits for use that model except less typing.

My vote is No.

[edit]
In the last months there are a lot of proposals to adopt C++ characteristics in FPC (i. e. "genercs"). I really don't like it. Object Pascal is a great language as it is. I think it doesn't need more.

[marcov]

And what does "but only within the scope of one procedure" mean?
The above can be used as a function result or var-parameter too.

But such use cannot contain any dynamic types. Pointers or ansistrings/dyn arrays.   The jury is still out if this is a feature or bug (see other parts in this thread), but Delphi does the same apparantly.

Note that virtual methods are useless, since you can't use polymorphism without explicite and runtime instantiation.

So it is just a record with methods in its namespace for all practical purposes. For traditional programming the difference between x.method and method(x) is not that big. It can be that it only gets important for systems that postpone typechecks (like for..in generics, anonymous methods etc), to reduce the search scope using duck-typing, which I suspect Delphi added the record-with-methods  for.

 

[Martin_fr]

And what does "but only within the scope of one procedure" mean?
The above can be used as a function result or var-parameter too.

But such use cannot contain any dynamic types. Pointers or ansistrings/dyn arrays.   The jury is still out if this is a feature or bug (see other parts in this thread), but Delphi does the same apparantly.

We are not talking a class/instance replacement => the initial question was records with methods.

The string/dyn-array issue only exists in objects that inherit from another object ("type = object(TSomeParentObject) end").

Records do not have inheritance.
So it is to the best of my knowledge safe to use "type = object" as a record-with-methods.

[Zaher]

Records do not have inheritance.
So it is to the best of my knowledge safe to use "type = object" as a record-with-methods.

I agree

[skalogryz]

Records do not have inheritance.
So it is to the best of my knowledge safe to use "type = object" as a record-with-methods.

they do have an explicit inheritance;

Code: [Select]

type
  TParent = record
    a : integer;
  end;

  TChildA = record
    p : TParent;
    b : integer;
  end;

  TChildB = record
    p : TParent;
    c : Integer;
  end;
...
procedure ChangeParent(var p : TParent);
...
var
  c1: TChildA;
  c2: TChildB;

ChangeParent(c1.p);
ChangeParent(c2.p);