why not properties in objects?

[damieiro]

Hi!
A stupid thing.. but
why aren't "sugar" syntax in objects and classes have it like properties? these schemes doesn't evolve the same?

[Thaddy]

1. Read some books about OOP.
2. Any TObject derived class can introduce properties.
3. do not try to enhance Tobject itself.
4. try to restrain your enthousiam a bit and check against computer science litarature.

The latter meaning you should derive, not enhance.... BASIC.

[damieiro]

Thaddym i really don't like the answer. Did i ask something wrong?

1. Read some books about OOP.
2. Any TObject derived class can introduce properties.
3. do not try to enhance Tobject itself.
4. try to restrain your enthousiam a bit and check against computer science litarature.

1.- I will not answer this.
2.- Object, no Class in FPC languaje. i don't know why a property is not used in object syntax but it is used on class syntax (what is this term concerned with OOP literacy?) .  https://wiki.freepascal.org/Property indicates that only for classes.
3.- Is off-topic. Is a thread for TObject with their own question. And if you read that thread you will see that i only want to make a read-only compiler-linker default in a read-write without OS dependant code. And i mark why the TObject implementation is hurting some options that could be not being hurt by simple coding and not to make me recompilate all by (unless well explained) the default used, and this is not a languaje issue, is a implementation issue. Go to that thread and explain what's wrong. I want to learn, not to being prophet of nothingless.
4.- Well, i am enthusiastic. I'm trying to be polite allways, perhaps is my spanish-blood  . If i have offended i show my apologize.

[PascalDragon]

A stupid thing.. but
why aren't "sugar" syntax in objects and classes have it like properties? these schemes doesn't evolve the same?

What do you mean? TP-style objects support properties just like Delphi-style classes except for mode TP (cause there the property keyword might be used as an ordinary identifier). (And no RTTI, because TP-style objects don't support RTTI)

[damieiro]

What do you mean? TP-style objects support properties just like Delphi-style classes except for mode TP (cause there the property keyword might be used as an ordinary identifier). (And no RTTI, because TP-style objects don't support RTTI)

Ok, that's the answer i needed. I will try. I only used the Class scheme and i go to doc and it says that were only for class. should be the doc wiki ambigous? I tried to find examples with properties in objects before coding and i didn't found anything in docs with an example with object. So for that reason was my doubt.

I saw this on wiki -> https://wiki.freepascal.org/Property and said (wrongly ) that is only for a class.

It was strange for me that doc reference. And i feel me a bit stupid with the question, but i would prefer to ask than to try and error.

[PascalDragon]

It was strange for me that doc reference. And i feel me a bit stupid with the question, but i would prefer to ask than to try and error.

The official documentation of the language as supported by FPC is the Language Reference Guide, not the Wiki. Tough to be fair the overview about objects does not mention properties either, so that should be reported as a bug against the documentation.

[damieiro]

Thaddy, PascalDragon. Yeah, some days i really feel stupid  . It was really a no brainer..

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

1.  
2. program classVsObject;
3.  
4. type
5.   TMyClass=class(TObject)
6.   private
7.     FTest:word;
8.   public
9.     property test:word read FTest;
10.   end;
11.  
12. type
13.   TMyObject=Object
14.     private
15.       FTest:word;
16.     public
17.       property test:word read FTest;
18.    end;
19.  
20. Var
21.   MyClass:TMyClass;
22.   Myobject:TMyObject;
23.  
24. begin
25. end.
26.  
27.  

[damieiro]

The official documentation of the language as supported by FPC is the Language Reference Guide, not the Wiki. Tough to be fair the overview about objects does not mention properties either, so that should be reported as a bug against the documentation.

Well, pascaldragon, i saw on this and it similar to wiki and i re-read with your comment.

https://www.freepascal.org/docs-html/current/ref/ref.html

Properties are on 6.7 (as class syntax), but not reference object syntax and no examples in 6.7. Am i missing something? (well, i have not exhaustively read all, but in 1st and 2nd read the first impression is that were class-biased syntax only). If is needed work force for docs, i would gladly help (specially in spanish, which is my native tongue, i do my best trying english..)

[PascalDragon]

You did also read the part where I said that the overview about objects is missing properties and that this should be reported as a bug? So, yes, it's indeed not mentioned in the documentation that objects can support properties and that should be fixed.

[MarkMLl]

Thaddy, PascalDragon. Yeah, some days i really feel stupid  . It was really a no brainer..

Also a unit can have properties, although they're only of limited use since there's no way of hiding the functions etc. that they refer to.

MarkMLl

[damieiro]

You did also read the part where I said that the overview about objects is missing properties and that this should be reported as a bug? So, yes, it's indeed not mentioned in the documentation that objects can support properties and that should be fixed.

ok!. I understand now that we were talking about the same . I understood that you were talking only about the wiki and the fpc doc was correct .  Ok, sorry for the misunderstanding.

[damieiro]

program classVsObject;

My understanding is that a class is code that you write and an object is computer memory allocated to an instantiated instance of a class. I hope I have expressed the relationship adequately.

Sorry for disrupting the thread. As for as the topic "why not properties in objects?" - well, why not??? I don't understand the question; sorry.

Well, the question is really answered and it was  a misunderstanding of object syntax i had. In documentation and examples one could interpretate that only classes had properties, but both objects and classes had properties. When i heard PascalDragon explanation, i tried the sample i post and both things are ok.
On the other hand, well, in FPC and object and a class doesn't have the samem academic meanings. Class is a heap memory type and object an stack memory type (if not made heap only) and both will be the "academic" class. When you instantiate any of these in a "academic" object one will be instantiated in heap memory and the other in stack memory. The topic from Classes and objects in FPC could be a looong thread. These aren't the only diferences. All classes descend from TObject class which has their own defaults and history. I think (INMHO, but devs are who really knows) these two pascal types should unificate or evolve to a more common ground, but the changes in backward compatibility and things like that are big issues. I would dream that in future heap or stack memory will be past, only memory, but probably i will die before it happens 

I put a code below with a perhaps too simple schema to show what i'm trying to say and comments.

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

1. program classVsObject;
2.  
3. // Some academic view
4.  
5. type
6.   TMyClassFPCClass=class(TObject)
7.   private
8.     FTest:word;
9.   public
10.     property test:word read FTest;
11.  
12.   end;
13.  
14. type
15.   TMyClassFPCObject=Object  // this is really a "academic" class too. I would love syntax will be TmyClass=Class
16.     private
17.       FTest:word;
18.     public
19.       property test:word read FTest;
20.    end;
21.  
22.  
23. Var
24.   MyInstanceFPCClass:TMyClassFPCClass;    //this is really a pointer, like MyInstanceFPCClass=^TMyClassFPCClass,
25.   MyInstanceObject:TMyClassFPCObject;     //this is a variable in stack.
26.  
27. begin
28.   //instantiation with FPC Class
29.   MyInstanceFPCClass:=TMyClassFPCClass.create; {instantiate object in heap memory}
30.   //MyInstanceFPCClass.init; {optional if init method declared}
31.   MyInstanceFPCClass.free; {free mem object in memory}
32.  
33.  
34.  
35. {  MyInstanceObject doesn't need to Instantiate in memory, it is created and wiped in the scope of the block.}
36. {obviously, both fpc class and object should take the values -> the instantiation in value
37.  
38. Other way of view is these:
39. FPC class: needs
40. 1.- Declaration (the type above)
41. 2.- Memory allocation
42. 3.- Init values -> academic instantiation.
43. 4.- Memory deallocation.
44.  
45. Points 2 and 3 are usually made in create. Some academic views like create and init.
46.  
47. FPC Object needs:
48. 1.- Declaration of the class (the type above)
49. 2.- Init values -> academic instantiation
50.  
51. As being a stack object, its allocation and deallocation is done by compiler in scope. It can be created on heap like any type.
52.  
53. }
54.  
55. end.                    

[PascalDragon]

My understanding is that a class is code that you write and an object is computer memory allocated to an instantiated instance of a class. I hope I have expressed the relationship adequately.

The problem is that Object Pascal has two independent object models: the TP-style object and the Delphi-style class. And then there are also the terms class and object of which the later indeed often is a synonym for an instance of a class, but in principle these terms apply to both object models. So if it isn't clear from the context (e.g. because we're talking about the LCL or something from the Classes unit) one should mention whether one is talking about TP-style or Delphi-style objects if one mentions object in the meaning of an instance.

[damieiro]

Well allthough i love fpc, i think that other problem is that academic literature of what is a class and what is an object says one thing and implementation in TP-style and delphi-style gives a lot of confusion and choosen names won't help.

it would be better that a Delphy style class will remain as it is (allthogh i dislike that TMyclass=class is same that TMyClass = class (TObject))
and tp objects would be Renamed (allthough accepted Object as old syntax) to some class like. For example Tmyclass= StackClass or something with Class keyword. Wirth spirit is readable code, not that a newbie has to do some non intuitive conversion which is vs readability. And free pascal is the most readable languaje i know. And my first-ever choice. But it has its quirks
And devs are doing a great job!, it seems that i only put on the critics, but i would not change pascal for nothing...

[PascalDragon]

it would be better that a Delphy style class will remain as it is (allthogh i dislike that TMyclass=class is same that TMyClass = class (TObject))
and tp objects would be Renamed (allthough accepted Object as old syntax) to some class like. For example Tmyclass= StackClass or something with Class keyword.

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).

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

Yes, it is.