[fpc-devel] Re: [fpc-l] type discussion

[listmember]

Marco van de Voort wrote:
> Some of these target functionality (specially in the linking section) might require restructures
> related to
>     * introduction of an internal linker for some core platforms (no more LD)
>     * Rewrite of module (unit) handling

Yes, these would be great, IMHO.

> For the rest, improve RTL/FCL compability and extend them in general, and of course fixbugs.
> 
>>Beside of compatibility towards Delphi or MacPascal or others FPC should be
>>open to other modifications/extensions (maybe Delphi one day copies FC a bt
>>:-), and not always the other way round)

Maybe a few things should be borrowed from RemObjects Chrome, such as

-- Class Contracts
http://www.remobjects.com/page.asp?id={DFA00D71-D5A4-40A3-9FD0-251899EB30D8}

I like the 'require/ensure' aproach.

It makes the code more robust and more debuggable, IMHO

-- Generics
http://www.remobjects.com/articles/?id={A1D08EE3-0D9E-4828-AFB3-B2C1E772186E}

I am not sure if Generics could be done in FPC.

-- Virtual Properties and Events
http://www.remobjects.com/page.asp?id={10E153AD-E05F-48CE-9CED-BCED5C9CDE99}

-- Enhanced Multicast Events
http://www.remobjects.com/page.asp?id={CC9C4828-9E49-4C41-AFD9-0BFFA4E9C3D3}

Inline variable initializers, such as:

type
   TSomethingElse = class(TSomething)
   private
     FInteger: Integer = 15;
     FBoolean: Boolean = False;
     FString: String = 'SOME TEXT';
     {etc}
   protected
   public
   published
   end;

Similarly, for

function Something(...): Boolean = False;
var
   Integer1: Integer = 15;
   Boolean1: Boolean = False;
   String1: String = 'SOME TEXT';
begin
end;

Procedure Something(Out AInteger: Integer = 12; ....);
var
   Integer1: Integer = 15;
   Boolean1: Boolean = False;
   String1: String = 'SOME TEXT';
begin
end;

>>Useful extensions I would see:
>>
>>bigger sets: set of -100000..100000 (e.g.)
> 
> I'd like that too. 

Me too.

>>a way to write integer constants in any base, not only
>>binary/octal/hexadecimal (not so important, but easy to implement)
> 
> Rarely used. Specially since more than base 36 becomes a notational 
 > problem. However it has been brought up before.

If someone contributes the code, why not. It does not hurt, IMHO.

>>writing of enums to text file;
> 
> This should be supported, however needs some tricks. (RTTI is available for enums!)

Yes. Ditto.

>>more operators which can be overloaded (should follow the ALGOL68 rules)
> 
> IMHO this is asking for a mess, and the use is limited.

Again, agreed.

>> multiple assignments:
>>
>>     a := b := c := d := 0 ;
>>
>>etc.
> 
> Same point. Totally useless.

Not really useful. More like confusing, to me, that is.