<div dir="ltr"><p dir="ltr">On Fri, Jul 17, 2015 at 1:32 PM, Michael Van Canneyt <<a href="mailto:michael@freepascal.org" target="_blank">michael@freepascal.org</a>> wrote:<br>
><br>
> On Fri, 17 Jul 2015, silvioprog wrote:<br>
>><br>
>> On Fri, Jul 17, 2015 at 11:24 AM, Graeme Geldenhuys <<br>
>> <a href="mailto:mailinglists@geldenhuys.co.uk" target="_blank">mailinglists@geldenhuys.co.uk</a>> wrote:<br>
>><br>
>>> On 2015-07-17 15:08, silvioprog wrote:<br>
>>>><br>
>>>> Using the generics I could do a generic<br>
>>>> DAO that could be used by any class, avoiding TPersonDAO, TProductDAO,<br>
>>>> TOtherMyEntityDAO and providing a simple and useful CRUD layer: just<br>
>>><br>
>>><br>
>>><br>
>>> I fully appreciate that there could be some uses, but I don't agree it<br>
>>> makes the language any better - in the contrary, it makes it much harder<br>
>>> to read. Pascal used to pride itself by being an easy to read and<br>
>>> understand language [by a human].<br>
>>><br>
>><br>
>> I agree with Michael too, but a nice thing to allow other programmers to<br>
>> make new libraries could be adding new features in the language, making it<br>
>> more productive.<br>
><br>
><br>
> Where is the proof that these new features make you more productive ?<br></p>
<p dir="ltr">Buddy, just 'googling' about 'new delphi rtti', 'delphi generics' or 'new delphi custom attributes' you can see many new Delphi XE frameworks available to download, and a lot of them use this new features and are very productive. But OK, I'm not going to insist about it anymore. ;)<br>
 <br>
> I created a code generator that creates boilerplate classes and associated unit test cases.<br>
> All with in essence D7 style code, ready to go.<br>
> I don't think that generics would do anything to improve the situation.<br>
> I could gain a few lines because I could use a generic list&enumerator, but that's it.<br></p>
<p>Nice job, I need to test it ASAP.</p><p dir="ltr">But, making FPC more compatible to XE, we could use more third party components, like Hprose[1]/EntityDAC[2]/TMS Aurelius[3]/DSWScript[4] etc.</p>
<p dir="ltr">>> I'm working in a new lib and I'm having several problems<br>
>> to keep compatibility betten FPC and Delphi, so I'm using a lot of IFDEFs,<br>
>> even using mode delphi.<br>
><br>
><br>
> To improve this situation I advocate NOT yet to spend effort on new<br>
> language modes, but first get the Delphi compatibility to a decent level.<br>
> I think that this will do more to help productivity than new modes.<br>
><br>
> After that, we can still see about new modes. I'm not arguing about that.<br>
><br>
> Michael.<br></p>
<p dir="ltr">Are you talking about compatibility to Delphi 5/7?</p><p dir="ltr">There are already many new great components available on network, however it uses some basic new Delphi features like I said above, but unfortunatelly FPC doesn't compile them.<br></p>
<p dir="ltr">In short, it isn't a problem to me and I'm glad to use ObjFPC even with some limitations, but I would be very greatful if the ObjFPC could be improved using at least generics, new RTTI and custom attributes. I know it would be a hard work to be able in FPC, but I can see a bit resistance from the FPC core to accept this new features (or nonsense, as they use to say =D ).</p>
<p dir="ltr">[1] <a href="https://github.com/hprose/hprose-delphi" target="_blank">https://github.com/hprose/hprose-delphi</a><br>
[2] <a href="https://www.devart.com/entitydac/" target="_blank">https://www.devart.com/entitydac/</a><br>
[3] <a href="https://www.tmssoftware.com/site/aurelius.asp" target="_blank">https://www.tmssoftware.com/site/aurelius.asp</a><br>
[4] <a href="https://bitbucket.org/egrange/dwscript" target="_blank">https://bitbucket.org/egrange/dwscript</a></p>
<p dir="ltr">-- <br>
Silvio Clécio<br>
My public projects - <a href="http://github.com/silvioprog" target="_blank">github.com/silvioprog</a></p>
</div>