Recent

Author Topic: OOP structures in fpc and Lazarus  (Read 21336 times)

jollytall

  • Full Member
  • ***
  • Posts: 209
Re: OOP structures in fpc and Lazarus
« Reply #60 on: December 09, 2021, 12:46:52 pm »
Thank you all for the comments.
I tried to rewrite the introduction and the advanced record parts to reflect more the above discussion, also linking information from herein.
I also added a new subchapter on the fail in inherited structures, as discussed here: https://forum.lazarus.freepascal.org/index.php/topic,57379.0.html

ArtLogi

  • Full Member
  • ***
  • Posts: 179
Re: OOP structures in fpc and Lazarus
« Reply #61 on: February 10, 2022, 12:11:21 am »
Any interest to say a few words about exceptions as they are objects, but are kind of threaded as separate case entirely in most of the time.. Really confusing to those who don't have found the key Exception are specialiced objects".. The clause "all objects are inherited from TObject and therefore start with T", but wait there is exception...   %)
While Record is a drawer and method is a clerk, when both are combined to same space it forms an concept of office, which is alias for a great suffering.

jollytall

  • Full Member
  • ***
  • Posts: 209
Re: OOP structures in fpc and Lazarus
« Reply #62 on: February 10, 2022, 08:42:47 am »
Interesting question. It indeed might worth few words in the next revision.
However, although Exception looks as something special it is not really. What is really special is the raise and the two structures to do something with the raised exception: try..finally..end and try..except..end.
If you look at the following code, it is perfectly valid:
Code: Pascal  [Select][+][-]
  1. program project1;
  2.  
  3. {$mode objfpc}
  4.  
  5. uses
  6.   SysUtils;
  7.  
  8. var
  9.   i : integer;
  10.  
  11. begin
  12. readln(i);
  13. try
  14.   if i = 2 then
  15.     raise TObject.Create();
  16. except
  17.   writeln('In except');
  18.   end;
  19. end.

The object (class instance) raised by raise does not need to be of class type Exception.
If you remove the try..except..end from the above program, it still prints an exception (if i = 2) on screen from SysUtils, like
Code: [Select]
An unhandled exception occurred at $00000000004010DA:
Exception object TObject is not of class Exception.
  $00000000004010DA  main,  line 12 of project1.lpr
If you even remove SysUtils, then you get a Runtime error, like
Code: [Select]
Runtime error 217 at $0000000000413FA2
  $0000000000413FA2
  $0000000000422D5C
i.e. SysUtils prints the message from the Exception if that is used to call raise, or prints the type of the class instance if it is not an Exception (or its descendant). You can try to raise an exception with other TObject descendants (I tried TStringList and it works the same).
If there is no SysUtils then a simple error message is generated as noone catches the raised exception.

The clause "all objects are inherited from TObject and therefore start with T", but wait there is exception...   %)
I might not know my doc well enough, but I do not remember this quote (and cannot find it in it, neither in the Wiki under Class). Is it from somewhere else? Btw. you can name your class type (almost) anything you want to, so those who wrote SysUtils were perfectly allowed to call their class type: Exception. To my taste TException would fit better, but "De gustibus non est disputandum".

PascalDragon

  • Hero Member
  • *****
  • Posts: 4318
  • Compiler Developer
Re: OOP structures in fpc and Lazarus
« Reply #63 on: February 10, 2022, 08:54:49 am »
The clause "all objects are inherited from TObject and therefore start with T", but wait there is exception...   %)

As jollytall wrote the first part is true for exceptions as well. The base type Exception inherits from TObject as well.

And regarding the name: those are up to the user anyway. The compiler isn't enforcing anything there. It's just that T is the usual prefix for types with a special exception (pun not intended) for exception types which start with E. This allows for a better distinction as the later are normally only used in the context of exception handling.

Warfley

  • Hero Member
  • *****
  • Posts: 910
Re: OOP structures in fpc and Lazarus
« Reply #64 on: February 10, 2022, 03:00:52 pm »
Really confusing to those who don't have found the key Exception are specialiced objects".. The clause "all objects are inherited from TObject and therefore start with T", but wait there is exception...   %)
Inheriting from TObject is not the reason they start with T, because otherwise, why doe TPoint or TRect, which are records start with T.

AFAIK the convention is so that custom types should in their name indicate what they are. Exceptions start with E (e.g. EConvertError), Interfaces with I (e.g. IUnkown) and Pointer with P (PInteger). All other types start with a generic T for Type (e.g. TPoint).

This is very usefull, if you have multiple related types like a TPoint is the record, PPoint is a pointer to the record, or a class TTest which implements interface ITest.
Even more so, as every type starts with such a prefix, functions and variables can have the name too, like the function Point that creates a TPoint. And following this convention can be really helpful to create a kind of constructor function with the same name of a type without the Prefix.

Also note that exceptions all inherit from Exception class is just a convention from the SysUtils unit, you can use exceptions with arbitrary objects as data (maybe even arbitrary pointers?)
« Last Edit: February 10, 2022, 03:02:58 pm by Warfley »

PascalDragon

  • Hero Member
  • *****
  • Posts: 4318
  • Compiler Developer
Re: OOP structures in fpc and Lazarus
« Reply #65 on: February 11, 2022, 12:47:07 pm »
Also note that exceptions all inherit from Exception class is just a convention from the SysUtils unit, you can use exceptions with arbitrary objects as data (maybe even arbitrary pointers?)

No, raise and the on-clause expect a TObject or a descendant thereof.

 

TinyPortal © 2005-2018