Recent

Author Topic: Free Pascal Standards  (Read 1155 times)

Ten_Mile_Hike

  • New Member
  • *
  • Posts: 44
Free Pascal Standards
« on: August 13, 2022, 11:56:12 pm »
Hello,
Except for one BASIC and one PASCAL class in 1982 (I used punch cards) I am self taught and therefore unfamiliar with many programming concepts. Could someone explain to me

1. WHY it is important that FPC maintains compatibility with Delphi as much as possible? (I'm NOT arguing that it should or that it shouldn't)

2. Related to the question above...I know how to manipulate the elements of a Tmemorystream  with "move" and "size" and other commands, but would it be against the
    compatibility doctrine to, for instance, add built in Procedures like "Leftmem,Rightmem, Midmem" functionality that works just like "Leftstr, Rightstr,
    Midstr". Yes; I realize that I could roll my own, that's not the point; what I'm trying to understand here is what is the doctrinal line between
    Delphi compatibility vs. new and innovative features.

Thank You

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11384
  • FPC developer.
Re: Free Pascal Standards
« Reply #1 on: August 14, 2022, 12:03:18 am »
Hello,
Except for one BASIC and one PASCAL class in 1982 (I used punch cards) I am self taught and therefore unfamiliar with many programming concepts. Could someone explain to me

1. WHY it is important that FPC maintains compatibility with Delphi as much as possible? (I'm NOT arguing that it should or that it shouldn't)

Simply the amount of code and people using it out there, compared to FPC/Lazarus.

Also the own FPC extensions are really not that great to begin with (IMHO).

Quote
2. Related to the question above...I know how to manipulate the elements of a Tmemorystream  with "move" and "size" and other commands, but would it be against the
    compatibility doctrine to, for instance, add built in Procedures like "Leftmem,Rightmem, Midmem" functionality that works just like "Leftstr, Rightstr,
    Midstr". Yes; I realize that I could roll my own, that's not the point; what I'm trying to understand here is what is the doctrinal line between
    Delphi compatibility vs. new and innovative features.

Probably too overspecialized for generic use, but you can always make a class helper.

Ten_Mile_Hike

  • New Member
  • *
  • Posts: 44
Re: Free Pascal Standards
« Reply #2 on: August 14, 2022, 12:38:20 am »
marcov,

Could you explain the advantages/disadvantages of creating a "class helper" vs writing a subroutine to accomplish a particular task?

Thank You

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11384
  • FPC developer.
Re: Free Pascal Standards
« Reply #3 on: August 14, 2022, 12:40:01 am »
Could you explain the advantages/disadvantages of creating a "class helper" vs writing a subroutine to accomplish a particular task?

A class helper seems to be part of the class to the programmer for straightforward use.

jamie

  • Hero Member
  • *****
  • Posts: 6091
Re: Free Pascal Standards
« Reply #4 on: August 14, 2022, 03:48:05 am »

 Syntax sugar I love it!

 If you are going to use an existed class in a lib you can simply add functionality to it and use that feature as a procedure or function so it can return data too.
 
 For example,
   
   SomeClass.MyAddOnThatWasntThereBefore(....)...


The only true wisdom is knowing you know nothing

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Free Pascal Standards
« Reply #5 on: August 14, 2022, 10:26:28 am »
Syntax sugar I love it!

Disagree. Much as I am opposed to gratuitous computersciency type stuff, if we accept the usefulness and importance of modularisation and opacity:

Code: Pascal  [Select][+][-]
  1. interface
  2.  
  3.   TFormPsTalk = class(TForm)
  4. ...
  5.   protected
  6.     fSerialThread: TThread;
  7. ...
  8.  
  9. implementation
  10.  
  11.   TSerialThread= class(TThread)
  12. ...
  13.  
  14. function TlocalFormPsTalk.getSerialThread(): TSerialThread;
  15.  
  16. begin
  17.   result := TSerialThread(fSerialThread)
  18. end { TlocalFormPsTalk.getSerialThread } ;
  19.  
  20.  
  21. type
  22.   TStationH=                            (* Avoid circular definition            *)
  23.     class helper for TStation
  24.     protected
  25.       function SerialThread(): TSerialThread; INLINE__
  26.     end;
  27.  

That's a crappy example but I think it's adequate to demonstrate that there is an application-wide thread represented opaquely globally (i.e. in the interface part of a unit), defined in detail in the implementation part, and accessible safely and concisely in the implementation part.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

jamie

  • Hero Member
  • *****
  • Posts: 6091
Re: Free Pascal Standards
« Reply #6 on: August 14, 2022, 03:41:10 pm »
whatever, I've saved tons of time by using them.

If I were on a CPU crunching crusade, then maybe I would examine the styles.

I guess it depends on how coding practices differs.
The only true wisdom is knowing you know nothing

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Free Pascal Standards
« Reply #7 on: August 14, 2022, 04:16:13 pm »
In my case, I've really used them to enforce type opacity and avoid circular references.

Wirth, in Modula-2, allows types to be opaque in the definition module but by doing so mandates that they are pointer-sized. That keeps the compiler nice and simple, but is a bit of an unfortunate restriction for a language that is much less heap- (hence pointer/reference-) oriented than is Object Pascal.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11384
  • FPC developer.
Re: Free Pascal Standards
« Reply #8 on: August 14, 2022, 04:29:48 pm »
I also see helpers as a kind of acknowledgement of the reality that all classes are not to be considered mutable, even in the long term.  Due to shared code with other applications, or because you are a mere user.

Users want to use stock releases of the development system and sometimes have to support multiple versions. Things like class helpers help to keep the core logic somewhat independent of such concerns.

 

TinyPortal © 2005-2018