Useful Oxygene Features for FPC?

[Shpend]

why not making all records/classes/objects automatically behave like tuples.

This means that, whenever you have such a (normal) case:

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

1.   type
2.     TRecord = record
3.        a: String[30];
4.        b: integer;
5.        c: boolean;  
6.     end;
7.  
8. so when you do this:
9.  
10. a, b, c: TRecord;
11. res: boolean;
12.  
13. res := (a = b) or (b = c) or (a = c)  //just some senseless Code...
14.  

You should be able to have it working like tuples by Default, that you can do all comparison stuff automaticall.

this is not possible by Default, you have to override all These Operators: [<>, =, <=, >= etc...] for it to work!

and then you have implicit tuples without the Need of creating a senseless new Concept

Not a good idea as the compiler's rule is to not allow custom operators when there is a build-in operator. And there are cases where you don't want to restrict what e.g. = compares as some information in the record might not be important for equality.

@Thaddy:
Nice, thx for the suggestions, but I tested your thing and it worked well, but i wanted to do the exact same but except, i wanted to change "Extension" to "Extensionof(<type>)" and he complains :O

here is how I did it 

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

1. program test;
2.  
3. {$mode objfpc}
4. {$modeswitch typehelpers}
5. {$macro on}
6. {$define name}
7. {$define extensionOf(name) := Type helper for name}
8. type
9.   TClass = class(TObject);
10.  
11.   TMyExtension = extensionOf(integer)
12.     const value = 100000;
13.   end;
14.  
15. begin
16. end.
17.  

FPC does not support macros with parameters. And before you ask for them: that idea was last rejected a few weeks ago.

1) Generics: why introduce a "generic/specialize" keyword, its actually unneseccarry to introduce because what we see as generic is the syntax: "TType<T>" and what we see as specialize is the syntax: "var field: TType<String>"

The use might not be apparent in type and variable declarations, but definitely in inline specializations. The following works in mode ObjFPC, but not in mode Delphi (if the specialize are removed) currently:

Code: [Select]

somevar := specialize SomeFunc<LongInt>(42) + specialize SomeOtherFunc<LongInt>(21);This is because types and routines can have variables and constants with the same name either in the same unit (not yet fully supported by FPC) or in different units. Thus in mode Delphi the compiler needs to decide whether SomeFunc< starts a generic or a comparison which it will only know for sure once it parses the final > which can be many tokens away. Especially if midway through it should realize that parsing it as a generic was an error than it needs to backtrack without any errors visible for the user and try again as an expression. This makes parsing such code really ugly.

OOP-MODEL:
  1) Class Contracts:
  2) Sequences and Queries
  3) Tuples + their behaviour more important
  4) Duck Typing + Soft Interfaces
  5) Cirrus/Aspect oriented Programming
  6) Nullable Types + the ":" operator

MULTITHREADING
  1) Lock
  2) Parallelism
  3) future types
  4) await + async

Well, there are some features that I indeed do plan to at least play around with. Most importantly tuples and class contracts.
The multithreading mechanisms would probably be provided by library code once we have support for anonymous routines cause we can then port the Spring4D framework.

@PascalDragon
Is  this now possible with CBlock-variant for anonymous types/methods?

This would be huge

[Shpend]

I mean btw the Spring4D stuff if this can be ported now to the maximum. SO only the entire Multithread stuff is for importance now.

[PascalDragon]

The CBlocks are macOS only and are only for interfacing with macOS libraries.

Anonymous functions are not yet available in FPC. Once they are we can talk again about Spring4D.

[Shpend]

Can u roughly elaborate, when they will be implemented, I m really interessted in this and generally:

can you (PascalDragon) or anyother working on FPC, provide a quick list what is still missing in terms of full-delphi-compatibility? Much much appreciated 

[440bx]

<snip> provide a quick list what is still missing in terms of full-delphi-compatibility?

For a request like that you should specify the Delphi version to compare to. 

For instance, Delphi supports (or is supposed to eventually support) inline variables and, it seems that feature isn't particularly welcome in FPC (justifiably so I might add.)

[jamie]

No, inline variables is not a welcome feature! thank you..

I've done my share of C/C++ coding and that is one thing that really bugs me...

However, I wouldn't mind the line variable for the FOR LOOP construct only, this way it stays restricted scope wise to the loop.

But putting them randomly through out the block of code is off my request of features !
----
 Putting that aside there is a feature I would like to have in Code tools for the IDE and that is to be able to popup in a window anywhere in a block of code the local VAR section or maybe a tree like structure I can look at on the fly as I am deep in a block of code where as the VAR section is off the editing sheet (not visible).

 Just wishing here, maybe its already there and don't know it ?

[Shpend]

@440bx
I would like to compare current FPC 3.2.0 with Delphi 10.4.(0/1)

[Peter H]

I think,nobody is forced to use inline variables in C++.
It is possible to declare all variables at the start of the block.

However, inline variables make automatic typing possible.
This can be important in templates.
C++:
auto const foo = [&] {do something;}
Delphi:
const foo = procedure begin dosomething; end;

How to do something like this without inline varables?
Maybe it is possible, but probably hairy.
I personally think it is good to have declaration, definition and initialization in one place, and to limit visibility of variables to the block where they are used.

[marcov]

@440bx
I would like to compare current FPC 3.2.0 with Delphi 10.4.(0/1)

Till say XE7, packages (being worked on), Anonymous methods (D2009) and extended RTTI(D2010).  Also since XE2, all units have been renamed to a namespace variant, FPC does support namespaces, but hasn't done (or planned) the rename. Later Delphis also add to units.

Some of the newer extensions also have already been abandoned meanwhile (like the automatic memory management).

Peter H: Your example doesn't really show why position matters.

[Shpend]

@marcov

sorry to say that, but I dont understand ur comment

what u mean with "til say XE7" and with "Anonymous methods (D2009) and extended RTTI(D2010)." u mean these are in work/progress or what u mean with this, sry but I cant get the semantic out of this comment. (no offense.-.)

[Awkward]

Also since XE2, all units have been renamed to a namespace variant, FPC does support namespaces, but hasn't done (or planned) the rename.

Very stupid idea to rename. what about compatibility with not stupid delphi managers but old sources? Create aliases - ok, rename existing - very bad idea.

[Peter H]

Peter H: Your example doesn't really show why position matters.

As soon  as the example becomes more complex:

const foo = function( a: <T>, b:integer):<T> begin access local variables of outer block end;

it should be obvious why it matters.
(I am not absolutely shure about the Delphi syntax here)

[marcov]

sorry to say that, but I dont understand ur comment

what u mean with "til say XE7" and with "Anonymous methods (D2009) and extended RTTI(D2010)."

I meant the main missing language features till XE7.

u mean these are in work/progress or what u mean with this, sry but I cant get the semantic out of this comment. (no offense.-.)

No, they are missing. Some are work in progress, but not all.

[PascalDragon]

Can u roughly elaborate, when they will be implemented, I m really interessted in this and generally:

It's done when it's done, simple as that.

can you (PascalDragon) or anyother working on FPC, provide a quick list what is still missing in terms of full-delphi-compatibility? Much much appreciated 

marcov already answered that. Though there are probably some smaller features that no one has on their radar right now.

[Zoran]

I think,nobody is forced to use inline variables in C++.

Please never use this argument.
Programming is not only writing new code, but also reading and understanding code written by others.
And in the end it is much more maintaining (often other people's) code, than writing new code.

This is not about "inline variables", but generally, saying "if you don't like this feature, you don't have to use it" is just very wrong.