Recent

Author Topic: Unified Pascal syntax  (Read 4541 times)

PascalDragon

  • Hero Member
  • *****
  • Posts: 2102
  • Compiler Developer
Re: Unified Pascal syntax
« Reply #15 on: December 15, 2019, 06:53:42 pm »
In my head, there shouldnt even be a need for a modeswitch to advanced records, it should be implicitly possibly
We are reluctant to enable new features by default in mode ObjFPC, cause we're trying to be as backwards compatible as possible. That would also answer the following question:
Is anyone of you attracted to the record/class idea I mentioed above?
No, we're not. There are more important things to work on, namely features like dynamic packages, anonymous functions, extended RTTI, improving optimizations than inventing yet another dialect (because that is all that it would be).

Like making records implicitly advanced and object-wise, like supporting everything that a class can but is still allocated on the stack.
Use the object type for that.

I feel this bringing a modeswitch into fpc feels very deprecated to me atleast.
The mode and modeswitch concept is a very strong point of FPC and easily allows it to incorporate multiple language dialects and to easily add new features without breaking existing code.

Sorry, confused message. 
I meant advanced records currently lack inheritance. Perhaps they always will?
That's the idea. If you need inheritance then use the appropriate type.

440bx

  • Hero Member
  • *****
  • Posts: 1993
Re: Unified Pascal syntax
« Reply #16 on: December 15, 2019, 07:26:49 pm »
I meant advanced records currently lack inheritance. Perhaps they always will?
Probably, because adding inheritance to advanced records would result in something that already exists: the old "object"  (or very close to it.)
FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

kupferstecher

  • Sr. Member
  • ****
  • Posts: 406
Re: Unified Pascal syntax
« Reply #17 on: December 15, 2019, 11:36:35 pm »
From my Pascal experience and understanding I expect Records to be plain data structures and Objects like the Classes to be the real OOP features. So for simplicity I'd rather hope that the advanced records are dropped.

Actually I quite liked using the Object type, especially as singleton. But I'm more and more reluctant because it is not fully compatible with the Class type. Override of methods e.g. is not possible and I stumbled into strange errors time by time. The problem for the missing features is, that in the beginning the object type seems to be enough and later I reach a point where incompatibilities occur, requiring to change to the class type. It's a rare case, but still I always have it in mind when I consider using the Object type. So it would be nice if the Object type would be further developed to be fully orthogonal to the Class type. E.g. a class could be derived from an object (and vice versa?).

On the other hand, the additional effort for just using a class is minimal, so perhaps its the best to constrain oneself to the class type (on systems with OS).

valdir.marcos

  • Hero Member
  • *****
  • Posts: 993
Re: Unified Pascal syntax
« Reply #18 on: December 16, 2019, 06:32:31 am »
Personally I think too detailed information hiding is counterproductive.
The benefits are in the first order aspects, the rest is micromanaging.
Informating hiding is hiding identifiers from others scopes (classes/units/whatever). I firmly believe in keeping that simple. (IMHO the whole "strict*" was already worse than the actual problem).  private/protected/public is good enough.
I basically agree. The problem is that the object pascal language has a peculiar notion of private (and protected), since a private member of a class is visible not only within the class to which it belongs, but also outside, within the unit where the class itself is defined. This does not happen for example in C++ and Java. Hence the need for the 'strict' keyword to restrict visibility.
That's what I meant with worse than the problem. The addition (and having six levels) is worse than the original problem (three levels with some shortcuts for use within the same unit).

Note that the exceptions are partially rooted in the unit system, a concept that  e.g. Java doesn't have, and C++ is only discussing about in committees. C++ is  30 years back  on that front, so it is logical that they don't support it.
Interesting.

PascalDragon

  • Hero Member
  • *****
  • Posts: 2102
  • Compiler Developer
Re: Unified Pascal syntax
« Reply #19 on: December 16, 2019, 09:17:25 am »
From my Pascal experience and understanding I expect Records to be plain data structures and Objects like the Classes to be the real OOP features. So for simplicity I'd rather hope that the advanced records are dropped.
No.
1. they are required for Delphi compatibility
2. it's necessary do declare operators, types, constants and such inside a record so that they can be used inside a generic's specialization

Actually I quite liked using the Object type, especially as singleton. But I'm more and more reluctant because it is not fully compatible with the Class type. Override of methods e.g. is not possible and I stumbled into strange errors time by time. The problem for the missing features is, that in the beginning the object type seems to be enough and later I reach a point where incompatibilities occur, requiring to change to the class type. It's a rare case, but still I always have it in mind when I consider using the Object type. So it would be nice if the Object type would be further developed to be fully orthogonal to the Class type. E.g. a class could be derived from an object (and vice versa?).
The object type is the old object system from Turbo Pascal times. As it was quite a bit different from the Delphi class types they do have their different behaviours. Thus it's also not possible to have one inherit from the other, because they present completely different concepts.
Also while we don't consider the object type to be deprecated (like Delphi does) we don't really have an intention to develop it further (though there might be exceptions like this feature request).

MarkMLl

  • Hero Member
  • *****
  • Posts: 1217
Re: Unified Pascal syntax
« Reply #20 on: December 16, 2019, 10:07:13 am »
The object type is the old object system from Turbo Pascal times.

What was that- Turbo pascal 5.5? I no longer have access to my manual collection, but I think it was in an addendum accompanying the TP5 manuals. And then Turbo Pascal for Windows introduced an early OO framework- OWL?

MarkMLl
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.


MarkMLl

  • Hero Member
  • *****
  • Posts: 1217
Re: Unified Pascal syntax
« Reply #22 on: December 16, 2019, 11:11:33 am »
> Do you mean "Turbo Pascal 5.5 OOP Guide"?

Looks about right. So from the copyright that was 1989... 30 years on FPC still doesn't break the core language and library (although things like CRT support are a problem).

MarkMLl
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.

lucamar

  • Hero Member
  • *****
  • Posts: 3017
Re: Unified Pascal syntax
« Reply #23 on: December 16, 2019, 02:02:57 pm »
What was that- Turbo pascal 5.5? I no longer have access to my manual collection, but I think it was in an addendum accompanying the TP5 manuals.

Borland expanded objects very quickly; every new release from TP 5.5 came with new features: private/public fields/methods, etc. FPC's objects are like the objects in the final TP 7.0
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus 2.0.8/FPC 3.0.4 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

glorfin

  • Full Member
  • ***
  • Posts: 100
Re: Unified Pascal syntax
« Reply #24 on: December 16, 2019, 02:44:39 pm »
From my Pascal experience and understanding I expect Records to be plain data structures and Objects like the Classes to be the real OOP features. So for simplicity I'd rather hope that the advanced records are dropped.
I would agree. I doubt that adding new and new syntactic features make a language really better.
Quote
Override of methods e.g. is not possible...
Why?? There is no key word "override" for old style objects, but you can have a virtual method and, in a heir type, define another method with the same arguments and virtual modifier - and it overrides the old one:
TMyFirstObject = object(TObject)
  .............
  MyMethod(param1:real):real; virtual;
end;

TMySecondObject = object(TMyFirstObject);
  .................
  MyMethod(param1:real):real; virtual;
end;
..................
TMySecondObject.MyMethod;
var
  MyVal:real;
begin
  MyVal := TMyFirstObject.MyMethod(Param1); // call to inherited method
  ..........
end;

Shpend

  • Jr. Member
  • **
  • Posts: 93
Re: Unified Pascal syntax
« Reply #25 on: December 16, 2019, 07:40:07 pm »
@PascalDragon

Quote
Thus it's also not possible to have one inherit from the other, because they present completely different concepts.

They may be like this, but the realy issue IMHO is, do they present equaly or kinda equaly the same within memory?
Isnt this the real question if there might be the motivation to make them fully compatible with eachother, since its a very powerful OOP feature if they would.

I know obviously, that a class is stored as a pointer to the date  which itself is on the heap, and object is pure date itself at the stack, but ignoring this for a second, they should be behave the same ,right?

lucamar

  • Hero Member
  • *****
  • Posts: 3017
Re: Unified Pascal syntax
« Reply #26 on: December 16, 2019, 07:59:26 pm »
I know obviously, that a class is stored as a pointer to the date  which itself is on the heap, and object is pure date itself at the stack, but ignoring this for a second, they should be behave the same ,right?

Not quite, and it depends on quite a lot of things: v.g. whether the object has virtual or dynamic fields/methods, and other things. In fact, AFAIK, most complex types are really pointers, under the hood, i..e the generated code takes the instance variable as pointing someplace (whether heap or stack) where the "real" data resides.

Also, old-style objects are not neccessarily stored in the stack (though they may be): if you use the extended New() and Dispose() to create them, for example, the instance data should be in the heap. Indeed, it couldn't be otherwise: given their size (for other than record-like objects) they would consume the stack fairly quickly.

The difference between old-style objects and classes is not big; it's just enough that to make them "compatible" is not the straight proposition it may sound like.
« Last Edit: December 16, 2019, 08:01:45 pm by lucamar »
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus 2.0.8/FPC 3.0.4 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

kupferstecher

  • Sr. Member
  • ****
  • Posts: 406
Re: Unified Pascal syntax
« Reply #27 on: December 16, 2019, 10:24:37 pm »
Thus it's also not possible to have one inherit from the other, because they present completely different concepts.
Do you mean on implementation/memory side or on syntax side?

Quote
Also while we don't consider the object type to be deprecated (like Delphi does) we don't really have an intention to develop it further.
Yes, I realized that. Except for embedded targets there also seems no need for the object type. But perhaps its also a henn/egg-problem. If there were full compatibility than maybe it would be used more, which could result in a higher motivation for improvements :)

I think of something like this:

Code: Pascal  [Select][+][-]
  1. Type TFoo = object
  2.   Procedure DoSomething;
  3. end;
  4.  
  5. var
  6.   Foo: array[0..5] of TFoo; //Static Memory
  7.   tempFoo: class(TFoo)      //variable of class type (reference)
  8.  
  9. begin
  10.   tempFoo:= Foo[1];
  11.   tempFoo.DoSomething;
  12.   //or even..
  13.   for tempFoo in Foo
  14.   do tempFoo.DoSomething
  15.  
  16. end;

This would allow the use of static memory and still avoid explicit pointer handling, when dealt with references.

Override of methods e.g. is not possible...
Why?? There is no key word "override" for old style objects, but you can have a virtual method and, in a heir type, define another method with the same arguments and virtual modifier - and it overrides the old one:
Thanks! I wasn't aware of that.

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8718
  • FPC developer.
Re: Unified Pascal syntax
« Reply #28 on: December 16, 2019, 10:32:58 pm »
Quote
Code: [Select]
  tempFoo:= Foo[1];
  tempFoo.DoSomething;
  //or even..
  for tempFoo in Foo
  do tempFoo.DoSomething
 
end;

This would allow the use of static memory and still avoid explicit pointer handling, when dealt with references.

Afaik for..in would copy foo
  • to tempfoo so you would be operating on a different object. So that won't work I guess.


kupferstecher

  • Sr. Member
  • ****
  • Posts: 406
Re: Unified Pascal syntax
« Reply #29 on: December 16, 2019, 10:47:31 pm »
(Thats hypothetical syntax.)

tempFoo was declared as class type, so it only contains the reference to the instance.

Code: Pascal  [Select][+][-]
  1. var
  2.   tempFoo: class(TFoo)

Internally the data structure of an instance of Class or Object would be the same, only the variable behaviour would be different.

 

TinyPortal © 2005-2018