why not properties in objects?

[damieiro]

No, because the purpose of FPC is to be compatible to existing code and in this case both TP and Delphi support object (and to add to the confusion: in mode MacPascal it's called object, but in fact it's a Delphi-style class; again this is due to compatibility). And nowadays it would also be part of backwards compatibility as there also exists code in mode FPC and ObjFPC that uses object (for example the compiler itself).

Yes, but what i wanted to say is that compiler will be being accepting "object" as you said in these Oses AND start adding aliases with keyword Class for the oldies "stack" objects so a declaration of and TP  object could be done with class-like keyword and old-fashioned keyword. Same as being used for destroy/done. But well, this is quite off-topic and more a wish-list. The main topic is answered and i only can say thanks to all.

Is this what PascalDragon is talking about when he says "TP-style object" vs "Delphi-style class"?

Yes. And i suffered the same unintuitive naming 

[PascalDragon]

No, because the purpose of FPC is to be compatible to existing code and in this case both TP and Delphi support object (and to add to the confusion: in mode MacPascal it's called object, but in fact it's a Delphi-style class; again this is due to compatibility). And nowadays it would also be part of backwards compatibility as there also exists code in mode FPC and ObjFPC that uses object (for example the compiler itself).

Yes, but what i wanted to say is that compiler will be being accepting "object" as you said in these Oses AND start adding aliases with keyword Class for the oldies "stack" objects so a declaration of and TP  object could be done with class-like keyword and old-fashioned keyword. Same as being used for destroy/done. But well, this is quite off-topic and more a wish-list. The main topic is answered and i only can say thanks to all.

No, that goes against orthogonality: there should be one way and one way only to use a specific language feature. Anything else will just confuse users even more, cause person A would continue to use the original way while person B would use the new way and then person A uses code from B or the other way round. This is not a wish-list, but you can put this on a "not-gonna-happen" list.

[damieiro]

No, that goes against orthogonality: there should be one way and one way only to use a specific language feature. Anything else will just confuse users even more, cause person A would continue to use the original way while person B would use the new way and then person A uses code from B or the other way round. This is not a wish-list, but you can put this on a "not-gonna-happen" list.

Well, i agree that orthogonality is a virtue, but if we check actual compiler options like .destroy or .done, several times orthogonality is pissed off.
And i do not agree. If way A is viewed as old-deprecated or for compatibility-only but way B is better, then i think it's a valid case.

But in this case is not necesary. A simple

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

1. type
2.    TStackClass = Object
3.    end;  
4.  

does the job if a dev want more intuitive naming. Which gives me an idea of a simple unit of renaming for my students.
It's not a needed feature  . Perhaps can be declared in classes or things like that or simply put as an example in manuals.

[PascalDragon]

No, that goes against orthogonality: there should be one way and one way only to use a specific language feature. Anything else will just confuse users even more, cause person A would continue to use the original way while person B would use the new way and then person A uses code from B or the other way round. This is not a wish-list, but you can put this on a "not-gonna-happen" list.

Well, i agree that orthogonality is a virtue, but if we check actual compiler options like .destroy or .done, several times orthogonality is pissed off.

We have no done in TObject. And if you mean Free then there is a difference between calling Destroy directly and calling Free.

And i do not agree. If way A is viewed as old-deprecated or for compatibility-only but way B is better, then i think it's a valid case.

And here I do not agree. Object Pascal already has enough keywords and functionality and what not. If there is no real reason for adding something new (and this would only be an existing feature with a new keyword) then we won't add it.

[MarkMLl]

And here I do not agree. Object Pascal already has enough keywords and functionality and what not. If there is no real reason for adding something new (and this would only be an existing feature with a new keyword) then we won't add it.

I'd suggest that adding a keyword (including custom operators) can be justified if the alternative is a non-intuitive overlay of an existing one: I'm thinking of TP's usage of "const" for static local variables here.

I'd also suggest however that adding keywords in a non-extensible language has unpleasant echoes of 1960s system software, which predated pervasive use of importable libraries (whether separately-compiled or not) with the result that even trivial naming or parameter changes had to be done by the compiler team.

MarkMLl

[damieiro]

We have no done in TObject. And if you mean Free then there is a difference between calling Destroy directly and calling Free.

No, i'm saying this:
compiler option:
-Ss        Constructor name must be init (destructor must be done)

Orthogonality would kill this compiler option, but here is. Same for C'ish operators like +=,++ etc...

I'd suggest that adding a keyword (including custom operators) can be justified if the alternative is a non-intuitive overlay of an existing one: I'm thinking of TP's usage of "const" for static local variables here.

This is a good example. "Static" or "local" should be the keyword here or similar one.
Really const used as static local variable is really "tricky" and need compiler options to not get warnings.. It's well documented, but first time i would need one, i have to read manual carefully and was counter intuitive the actual solution. I think const* here is overloaded.

It's easy to get examples:

const: Overloaded (many uses) and counter intuitive in static local
object: confusing because it really means StackClass.
operators: taking pascal and allowing C'ish.
method: constructors with double syntax..

I do not say that this is bad. I simply say that some kind of "normative" FreePascal with one way to do things it's a desirable one as pointed PascalDragon. I agree fully with this.  But, in the middle ground, i think that correctness, and saying correctness as the way to have at least one tool for devs to write intuitive, formal-academic naming, etc should be supported. (correctness as readability like Wirth's definition)

For above examples, it could imply (examples, not being hard thinking only for showing idea):
- const: Overloaded (many uses) and counter intuitive in static local -> Make a Static or similar keyword and adopt these like in C. A common sample is that my C-student doesn't know that Pascal has it..
- object: confusing because it really means StackClass. -> Bored of explaining really is a class.
- operators: taking pascal and allowing Cish. -> Well, these are handy, i won't change these, but or we accept things like const/static in part one or we don't... Pascal enforces assignment with := (<-) and not to use foo++ but inc(foo) or foo:=foo+1;
- method: constructors/destructors with double syntax.. -> I would enforce one, and mark other as deprecated, but still acepted by compiler.

By the way, what i'm trying to say is that for many historical reasons, we have several ways/aproachs for doing same things. I think that it's not bad to make a "high mountain see" and look what is better, what is intuitive, what not, and go for these maintaining backward compatibility. I'm not saying breaking the toy, only enhacements.

[PascalDragon]

We have no done in TObject. And if you mean Free then there is a difference between calling Destroy directly and calling Free.

No, i'm saying this:
compiler option:
-Ss        Constructor name must be init (destructor must be done)

Orthogonality would kill this compiler option, but here is.

That option was introduced way in the past (before the first CVS commit even). I don't know why it is there, but it might be something with migration from TP-style objects to Delphi-style classes or to enforce the use of Init and Done inside objects. I don't even know if anyone is really using that option and in case of Destroy in context of Delphi-style classes it might even lead to problems, because TObject.Free is calling Destroy (another point that this might have originally been meant only in the context of TP-style objects and should in fact not be used with Delphi-style classes).

Same for C'ish operators like +=,++ etc...

The C-style operators where added in a time when the devs had a less clearer picture of language consistency. Nowadays they definitely wouldn't be added anymore, but we have them now and are now part of the "backwards compatibility" baggage.

Note: we don't support the ++ (or --) operator, that has always been the domain of Inc and Dec.

[MarkMLl]

The C-style operators where added in a time when the devs had a less clearer picture of language consistency. Nowadays they definitely wouldn't be added anymore, but we have them now and are now part of the "backwards compatibility" baggage.

I'd be happy to see them removed, provided that they were replaced by sufficiently-flexible macro expansion.

MarkMLl

[PascalDragon]

The C-style operators where added in a time when the devs had a less clearer picture of language consistency. Nowadays they definitely wouldn't be added anymore, but we have them now and are now part of the "backwards compatibility" baggage.

I'd be happy to see them removed,

I'd be happy, too, but as I said: backwards compatibility.

provided that they were replaced by sufficiently-flexible macro expansion.

That gets a definite No.

[MarkMLl]

That gets a definite No.

As anticipated. So I'd not be happy to see them go.

MarkMLl

[damieiro]

That option was introduced way in the past (before the first CVS commit even). I don't know why it is there, but it might be something with migration from TP-style objects to Delphi-style classes or to enforce the use of Init and Done inside objects. I don't even know if anyone is really using that option and in case of Destroy in context of Delphi-style classes it might even lead to problems, because TObject.Free is calling Destroy (another point that this might have originally been meant only in the context of TP-style objects and should in fact not be used with Delphi-style classes).

Ok, thanks for the response. Now i have a better view of devs road. And i like that.

Some of implicit question that was in the first post of this thread is if TP-Style objects will be an ok full-supported feature of the languaje like Delphi-classes or TP-Style objects will be deprecated in the long run or not. (i would like no, there are more that Stack/heap use differences, as the lightweight of these, forced inheritance, etc). Or if there would be some convergence road or some kind of view with these.

On the other hand, .free/.destroy it's a pain, but i also understand their story.

[PascalDragon]

Some of implicit question that was in the first post of this thread is if TP-Style objects will be an ok full-supported feature of the languaje like Delphi-classes or TP-Style objects will be deprecated in the long run or not. (i would like no, there are more that Stack/heap use differences, as the lightweight of these, forced inheritance, etc). Or if there would be some convergence road or some kind of view with these.

Delphi considers them as deprecated, but we don't. However that does not mean that we'll extend them any further only that we'll keep them working along the way and fixing bugs.

I may be mistaken but I believe TP-style objects have been deprecated for many many years already. This thread reads like an attempt to normalize French and Latin; it ain't gonna happen.

As said: they are considered deprecated by Delphi, but not by us.

[damieiro]

Delphi considers them as deprecated, but we don't. However that does not mean that we'll extend them any further only that we'll keep them working along the way and fixing bugs.

This give me some questions:
1.- Why delphi considers them as deprecated and FPC not? (i think should never be deprecated)
2.- If classes will be extended with any syntax, will objects be extended same way or not?

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?

[MarkMLl]

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

Why not ask the current owners (whoever they are)?

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 better clearly perhaps doesn't aply as before.

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. Think for example of the SPARC stack, which is on-chip but then spills to main memory once the allocation has been exhausted. Plus there have have been a number of microcontrollers with constrained stack space or semantics... which might have entered into their architectural planning even if they had no immediate plans to support them.

MarkMLl

[damieiro]

Why not ask the current owners (whoever they are)?

Well, i'm asking the fpc devs, it doesn't matter me what Delphi owners do. I disagree with many embarcadero choices. Devs here made tp-objects still maintained, but i would like why here is maintained and not enhanced and if a classes enhancement would be correlated by an object enhancement (seem plausible), otherwise is seeing that it will be deprecated somehow . A enterprise not maintaining anything is in nearly all cases a €€€ matter

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. Think for example of the SPARC stack, which is on-chip but then spills to main memory once the allocation has been exhausted. Plus there have have been a number of microcontrollers with constrained stack space or semantics... which might have entered into their architectural planning even if they had no immediate plans to support them.

This is correct, but i were thinking on pc. And memory is really cheaper. There is even some kind of academic discussion about if heap memory could be in some years a kind of past (i think not).
Being teorically-pure, a stack that is not correlative should'nt be called stack, and if it exhausted, should not allocate. SPARC stack, allthough called so, its working as an hybrid. And, curiosly, perhaps it could be one way of unifing stack and heap (it this is possible), but losing physical memory continuity (which is not a needed/desirable thing per se)