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

[silvioprog]

On Thu, Jul 16, 2015 at 6:44 PM, Michael Van Canneyt <michael at freepascal.org
> wrote:
>
> On Thu, 16 Jul 2015, Maciej Izak wrote:
>
>> 2015-07-16 17:23 GMT+02:00 Sven Barth <pascaldragon at googlemail.com>:
>>
>>       Then let me tell you that generic methods will arrive in mode
>> ObjFPC (and thus its syntax) first, because the Delphi syntax is a PITA to
>> parse/handle.
>>
>>       (in fact generic methods are already working in mode ObjFPC in my
>> local repo, I just want to get the Delphi ones working a little bit before
>> commiting to trunk)
>>
>>
>> @Sven, @Michael
>>
>> I am using generics all the time for many things.
>>
>> IMO using "generic/specialize" syntax because it is more simple to
>> implement in compiler is very strange motivation. Using specialize keyword
>> maybe is good in pure theory but is non practical
>> (generic keyword in type declaration is not so bad).
>>
>> You can torture me (!!!) but I will not use so many unnecessary words for
>> simple things.
>> By using this complicated syntax you will kill all functional/generic
>> approach.
>>
>
> No problem. Use mode Delphi then, that's what it is for.
>
> <sarcasm>
> Why bother with mode objfpc ? It only makes life more difficult. You need
> to use @ when there is no need really, you are restricted in your choice of
> names. Why use it at all ?
> </sarcasm/>
>
> And you are discussing with the wrong person. I don't think generics are
> very useful to begin with.
> I can see a use case for a simpler declaration of collections, but that's
> about it.
>

Buddy, with generics you can do other things besides fast creation of
lists. =) Please take a look at this little sample below.

Generics are very useful, and one of many possibilities that generics
provides is the "compilation time validation", for example, see this small
code below:

=== begin code ===

TPersonDao = class(TObject)
public
  procedure Save(APerson: TObject);
end;

TPersonDao.Save(APerson: TObject);
begin
  if not (APerson is TPerson) then
    raise EPersonDaoInvalidType.CreateResFmt(@SInvalidEntityClass,
[APerson.ClassName, TPerson.ClassName]);
  // other codes for TPerson persistance ...
end;

=== end code ===

This code above will check if the instance of my parameter is from a
TPerson class, if so, persist it, otherwise raise an exception. It avoids
something like this:

=== begin code ===

var
  VProduct: TProduct;
  ...
  VSomePersonDao: TPersonDao;
begin
  ...
  VSomePersonDao.Save(VProduct); // a type, for example (mistakes happen,
we are human =D )

=== end code ===

OK, it will raise an exception "Cannot persist a 'TProduct' using a
'TPersonDao'". Nice, but this error will be showed in production and for my
customer, and it is very bad. =/ Using generics you can avoid it:

=== begin code ===

TPersonDao<T> = class(TObject)
public
  procedure Save(APerson: T);
end;

TPersonDao.Save(APerson: T);
begin
  // the codes for TPerson persistance ...
end;

=== end code ===

It does not need EPersonDaoInvalidType, because:

=== begin code ===

var
  VProduct: TProduct;
  ...
  VSomePersonDao: TPersonDao<TPerson>;
begin
  ...
  VSomePersonDao.Save(VProduct);

=== end code ===

The compiler will stop the compilation saying something like "Incompatible
specialization type in 'TPersonDao', got 'TProduct', expected 'TPerson'".
So one more runtime error will be avoided.

And you can do more:

TSessionDao.Persist<TPeson>(VPerson); // inline specialization

or:

VPersonList := TSessionDao.Load<TPeson>; // inline specialization avoinding
casts

It is only some of many generic possibilities.

Silvio mentioned his company is moving to Node.js. That means Javascript. I
> program Javascript myself. Javascript is an unbelievably primitive
> language, yet is is increasingly popular.


=)

We are using Object Pascal in a desktop ERP written with Delphi 7, and
currently we are migrating some our modules to the XE8 (unfortunatelly XE8
is pretty expensive, but ... =/ ). Our ERP has many online features like
online registration, SMS/e-mail notifications, reports, charts, and
provides several resources for Android/Web via a SSL API written with
FCL-Web/Brook, and it is working perfectly, but our productivity is a bit
slow for to do new features, because -- and unfortunately -- it is
increasingly difficult to find professionals interested in Delphi/Pascal
programming. =(

Currently I made a wery fast websocket server[1] using Node.js, and I had
some dificult to find an updated WS Pascal client compatible with FPC 3 and
XE8, so I found one called Bauglir websocket, after some changes I could
compile it in both compilers. But I found some comercial clients, but
unfortunatelly it could not compile in FPC because they are using generic
classes from the Delphi Generic.Collections. Ironically, there are zillions
WS clients written in JS.

To me, that tells me that all these additions to Object Pascal which
> everyone claims are 'so essential' are in fact pure nonsense. Eye candy to
> make it look modern.


Buddy, I don't think so. Pascal is a very nice language, but it could be
modernized to be compatible with the current very fast necessity of our
customers, allowing us to do core more fast, and this new features
(generics, custom attributes etc) could be very helpful. Yes, in mantis
there are already many more important issues to be fixed, but we can see
some people interested in helping to do these new features, so IMHO I think
it would be interesting to hear them a little more. =)

Sure, I can't speak more to avoid being a little off-topic hehe.

[1] - wss://duallsistemas.com.br:8001/ (the public version is just a echo
server using the 'echo-protocol' as protocol, you can use a terminal[2] for
test it).
[2] -
https://chrome.google.com/webstore/detail/dark-websocket-terminal/dmogdjmcpfaibncngoolgljgocdabhke

-- 
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/20150716/4fb1eaf8/attachment.html>