[fpc-pascal] Interface syntax: Is possible don't use specialize in mode objfpc?

silvioprog silvioprog at gmail.com
Fri Jul 24 05:24:57 CEST 2015


On Fri, Jul 17, 2015 at 1:32 PM, Michael Van Canneyt <michael at freepascal.org>
wrote:
>
> On Fri, 17 Jul 2015, silvioprog wrote:
>>
>> On Fri, Jul 17, 2015 at 11:24 AM, Graeme Geldenhuys <
>> mailinglists at geldenhuys.co.uk> wrote:
>>
>>> On 2015-07-17 15:08, silvioprog wrote:
>>>>
>>>> Using the generics I could do a generic
>>>> DAO that could be used by any class, avoiding TPersonDAO, TProductDAO,
>>>> TOtherMyEntityDAO and providing a simple and useful CRUD layer: just
>>>
>>>
>>>
>>> I fully appreciate that there could be some uses, but I don't agree it
>>> makes the language any better - in the contrary, it makes it much harder
>>> to read. Pascal used to pride itself by being an easy to read and
>>> understand language [by a human].
>>>
>>
>> I agree with Michael too, but a nice thing to allow other programmers to
>> make new libraries could be adding new features in the language, making
it
>> more productive.
>
>
> Where is the proof that these new features make you more productive ?

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

> I created a code generator that creates boilerplate classes and
associated unit test cases.
> All with in essence D7 style code, ready to go.
> I don't think that generics would do anything to improve the situation.
> I could gain a few lines because I could use a generic list&enumerator,
but that's it.

Nice job, I need to test it ASAP.

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.

>> I'm working in a new lib and I'm having several problems
>> to keep compatibility betten FPC and Delphi, so I'm using a lot of
IFDEFs,
>> even using mode delphi.
>
>
> To improve this situation I advocate NOT yet to spend effort on new
> language modes, but first get the Delphi compatibility to a decent level.
> I think that this will do more to help productivity than new modes.
>
> After that, we can still see about new modes. I'm not arguing about that.
>
> Michael.

Are you talking about compatibility to Delphi 5/7?

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.

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

[1] https://github.com/hprose/hprose-delphi
[2] https://www.devart.com/entitydac/
[3] https://www.tmssoftware.com/site/aurelius.asp
[4] https://bitbucket.org/egrange/dwscript

-- 
Silvio Cl├ęcio
My public projects - github.com/silvioprog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20150724/0aa3efe3/attachment.html>


More information about the fpc-pascal mailing list