why not properties in objects?

[Handoko]

... but i would like why here is maintained and not enhanced ...

I believe it is manpower issue. Not much users are interested to use it but some still need it to compile/run some old codes.

[kupferstecher]

Whatever the merits of local stack storage vs a heap which can get fragmented, you can't rely on being able to store entities of arbitrary size on it.

Is it really on the stack? If I declare an instance of an object type as global variable, isn't that placed in the data section and not on the stack? So the stack limitations shouldn't hold for that?

On target embedded I use object a lot, because its lightweigth and I don't use a memory manager, so class wouldn't work. Just today I'm programming for a STM32.

For PC-programming I totally dropped using type object because of some minor incompatibilities. But I should give it a try once more.

[damieiro]

is it really on the stack? If I declare an instance of an object type as global variable, isn't that placed in the data section and not on the stack? So the stack limitations shouldn't hold for that?

good point. A global variable (as far i know) is a static one, so it should be allocated in compile-time, not dinamically. But.. if declared with a const like a static one in local?.

I believe it is manpower issue. Not much users are interested to use it but some still need it to compile/run some old codes.

Well, i think in it more than on old codes. I think in usability as kupferstecher. delphi-class also has it's quirks (derivating by TObject.. etc). Object serves to mimic c++ code that could be useful on some environments. And i do not know how to do a class without all the bloat in FPC using delphi-classes. The most similar is TP-object style.
Some times i would like that delphi-class Tobject could be a derivative for some form of minimal class. So TReallyMinimalClass-> TObject-> etc.. but i do not know deeply all the issues it could be.

[PascalDragon]

1.- Why delphi considers them as deprecated and FPC not? (i think should never be deprecated)

Because the modern Object Pascal is completely designed around Delphi-styled classes, TP-style objects play absolutely no role there. In addition to that they're buggy in Delphi.

2.- If classes will be extended with any syntax, will objects be extended same way or not?

No. TP-style objects are maintained, but not extended. We ensure that they're working, but nothing more.

3.- Stack based tp-objects have some interesting properties (as we know) like less memory consumption (lightweighted), these are fastest (for being in stack), guaranteed to be freed (all are local variables), memory correlation (as stack). And stacks issues aren't like a lot of years with very limited stacks. Today we can have a very big stack. So, the paradigm, which classes were selected choice, perhaps doesn't apply as before. Is there some other reasoning for letting tp-objects not with active extensions? Was/is an active debate with these questions?

And as soon as you need to use polymorphism you need to either use the heap or use Delphi-style classes cause then you can't use stack allocation or compile time allocation (global variables). And as long as you don't need inheritance you can just as well use an advanced record.

Whatever the merits of local stack storage vs a heap which can get fragmented, you can't rely on being able to store entities of arbitrary size on it.

Is it really on the stack? If I declare an instance of an object type as global variable, isn't that placed in the data section and not on the stack? So the stack limitations shouldn't hold for that?

On target embedded I use object a lot, because its lightweigth and I don't use a memory manager, so class wouldn't work. Just today I'm programming for a STM32.

For PC-programming I totally dropped using type object because of some minor incompatibilities. But I should give it a try once more.

The embedded platform is indeed one of those that benefits the most from objects (or advanced records).

[damieiro]

And as soon as you need to use polymorphism you need to either use the heap or use Delphi-style classes cause then you can't use stack allocation or compile time allocation (global variables). And as long as you don't need inheritance you can just as well use an advanced record.

Please, explain it more. I'm not a compiler expert.
Polymorphism can be (as long as i know) compile-time and run-time (virtual/override).
i think that vmt should be on data section of program, not heap (is this like this?)
and tp-objects are on stack.. what is the use of heap on tp-objects? Sorry if it's a dumb question.

[PascalDragon]

And as soon as you need to use polymorphism you need to either use the heap or use Delphi-style classes cause then you can't use stack allocation or compile time allocation (global variables). And as long as you don't need inheritance you can just as well use an advanced record.

Please, explain it more. I'm not a compiler expert.
Polymorphism can be (as long as i know) compile-time and run-time (virtual/override).
i think that vmt should be on data section of program, not heap (is this like this?)
and tp-objects are on stack.. what is the use of heap on tp-objects? Sorry if it's a dumb question.

Assume you have the following:

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

1. type
2.   TMyObject = object
3.     f: LongInt;
4.   end;
5.  
6.   TMySubObject = object(TMyObject)
7.     f2: LongInt;
8.   end;

If you now have a stack variable o: TMyObject you can never allocate that as a TMySubObject instead you must declare it as TMySubObject from the beginning (though yes, you can pass that along to something that takes a TMyObject and thus in so far polymorphism is possible). If you allocate it on the heap you can allocate a TMySubObject for a PMyObject instead. Thus you can never have the same flexibility with stack or static allocated objects than with heap ones.

[damieiro]

Assume you have the following:

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

1. type
2.   TMyObject = object
3.     f: LongInt;
4.   end;
5.  
6.   TMySubObject = object(TMyObject)
7.     f2: LongInt;
8.   end;

If you now have a stack variable o: TMyObject you can never allocate that as a TMySubObject instead you must declare it as TMySubObject from the beginning (though yes, you can pass that along to something that takes a TMyObject and thus in so far polymorphism is possible). If you allocate it on the heap you can allocate a TMySubObject for a PMyObject instead. Thus you can never have the same flexibility with stack or static allocated objects than with heap ones.

Well, and what i would need to allocate TMyObject as TMySubObject? I understand you (reverse has sense), but i dislike this kind of coding, even with heap classes (the child could have more fields, so better freeing and doing a new one in most cases). It would made sense the inverse (a son typed like her ascendant for methods for all classes like .free). And if even needed, isn't avaiable typecasting and and objects doesn't accept a child one? I think the practical flexibility is nearly the same.

[MarkMLl]

i think that vmt should be on data section of program, not heap (is this like this?)

I don't. The VMT should by default have the same protection as code, and self-modifying code is widely deprecated... I'd go stronger and say derided.

It would be one thing if you had a system with fine-grained protection where you could say "/This/ block of code is to be able to modify /that/ table in memory, and then to lock it permanently". However even then it would be a magnet for bugs and malware writers.

MarkMLl