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

[Marco van de Voort]

> 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.

Glorified asserts. This is inventing syntax for marketing reasons.

> It makes the code more robust and more debuggable, IMHO

Nope. It just is a limited form of assert with special syntax. Definitely
does not mark the trival syntax test.

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

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

Probably yes, however it will not be easy. IMHO Generics/templates are
definitely on the list, but don't expect it anywhere soon, unless there is
massive help.
 
> -- Virtual Properties and Events
> http://www.remobjects.com/page.asp?id={10E153AD-E05F-48CE-9CED-BCED5C9CDE99}

Understandable. However lots of performance issues. One could mitigate some
of these by e.g. requiring virtual properties to only use static methods and
adding optimizations.

RemObject/.NET probably either don't care about speed, and/or have some 
global optimalisations that makes adding this kind of stuff not to hurtful.

Probably a bit of both.

IMHO not a definite no, it would be either unoptimal, or a lot of work.

> -- 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;

Can be done otherwise (simply init it). -> Syntactic sugar.
 
> Similarly, for
> 
> function Something(...): Boolean = False;
> var
>    Integer1: Integer = 15;
>    Boolean1: Boolean = False;
>    String1: String = 'SOME TEXT';
> begin
> end;

Useless IMHO. Equal to above (initialising in syntax what can be inited normally)
 
> Procedure Something(Out AInteger: Integer = 12; ....);
> var
>    Integer1: Integer = 15;
>    Boolean1: Boolean = False;
>    String1: String = 'SOME TEXT';
> begin
> end;

Same. Don't even add to productivy
 
> >>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.

Because the more features, the more involved maintainance of the compiler
becomes. So keep that work for features that are worth it.

I don't like this one, but it might already exist (in mac mode), since ISO
Paslla has this.