> 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. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
