Re: [fpc-pascal] Food for thought - language string improvement

[Florian Klaempfl]

Am 10.07.2017 um 15:00 schrieb Sven Barth via fpc-pascal:
> Am 10.07.2017 13:19 schrieb "Michael Van Canneyt"
> >:
>>
>>
>>
>> On Mon, 10 Jul 2017, Felipe Monteiro de Carvalho wrote:
>>
>>> On Mon, Jul 10, 2017 at 1:08 PM, Michael Van Canneyt
>>> > wrote:

 The code is definitely not the same. In each case, it was measured.
> There is
 a 10% performance loss.
>>>
>>>
>>> I'd love a source on this one. I guess you mean in Free Pascal?
>>
>>
>> Obviously.
>>
>> The classes unit can be recompiled to use the fgl (well, that used to
> be so)
>> as a basis. When using the resulting list and stringlist, there was a 10%
>> performance loss. The main reason - If I recall correctly - was that
> the fgl needs to resort to move() operations instead of direct assignments.
> 
> The fgl classes don't use Move(), but they have a virtual method that
> does the assignment between the specialized parameters that's inherited
> from the non-generic parent list type.

... which is done to avoid bloat. fgl specialized only a wrapper around
an internal list. So the slightly slower code in some cases reduced
executable size.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[noreply]

On 2017-07-08 08:29, Ched wrote:

Is this acceptable ?


'SELECT Customers.CustomerName, Orders.OrderID' +
'FROM Customers' +
'FULL OUTER JOIN Orders' +
'ON Customers.CustomerID = Orders.CustomerID' +
'ORDER BY Customers.CustomerName;'


I think that one have to insert space at some loactions:
'SELECT Customers.CustomerName, Orders.OrderID' +
' FROM Customers' +
' FULL OUTER JOIN Orders' +
' ON Customers.CustomerID = Orders.CustomerID' +
' ORDER BY Customers.CustomerName;';

Cheers, Ched



And if it is a multiline string, the compiler may have to convert 
carriage return/new line into a space for you, to allow it to take:


FROM Customers
FULL OUTER JOIN Orders

and convert the carriage return after "Customers" into a space for you..

otherwise it will be:

FROM CustomersFULL OUTER JOIN Orders

..concatenated without a space

Something to be concerned about if implementing it.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Dmitry Boyarintsev]

On Mon, Jul 10, 2017 at 11:19 AM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:

> Though you can't use the same code block for multiple types.
>
Structured development to the rescue :)

===
program project1;

{$mode delphi}
{$RANGECHECKS on}

uses SysUtils;

function HandlingIt(const e: exception): Integer;
begin
  writeln('something bad has happened:');
  writeln(e.message);
  Result:=0;
end;

function Catch(a,b: byte; oper: char): byte;
begin
  try
if oper = '+' then Result:=a+b
else if oper = '/' then Result:=a div b;
  except
on e: EDivByZero do begin
  writeln('division by zero');
  Result:=0;
end;
on e: EIntOverflow do Result:=HandlingIt(e);
on e: ERangeError do Result:=HandlingIt(e);
  end;
end;

begin
  writeln( catch (1,1,'+'));
  writeln( catch (255,255,'+'));
  writeln( catch (1,0,'/'));
end.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Sven Barth via fpc-pascal]

Am 10.07.2017 15:46 schrieb "Graeme Geldenhuys" <
mailingli...@geldenhuys.co.uk>:
>
> On 2017-07-10 13:34, Dmitry Boyarintsev wrote:
>>
>> are you referring to "Catching More Than One Type of Exception with One
>> Exception Handler" in
>> https://docs.oracle.com/javase/tutorial/essential/exceptions/catch.html
>
>
> Yes. You can have multiple catch blocks inside the same try block. You
can also have a single catch block with a comma separated list of exception
types.

You can catch multiple exception types in Object Pascal as well:

=== code begin ===

try
expect
  on e: EWhatever do ...;
  on e: EFoobar do ...;
  else ...
end;

=== code end ===

Though you can't use the same code block for multiple types.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Dmitry Boyarintsev]

On Mon, Jul 10, 2017 at 9:46 AM, Graeme Geldenhuys <
mailingli...@geldenhuys.co.uk> wrote:

> On 2017-07-10 13:34, Dmitry Boyarintsev wrote:
>
>> are you referring to "Catching More Than One Type of Exception with One
>> Exception Handler" in
>> https://docs.oracle.com/javase/tutorial/essential/exceptions/catch.html
>>
>
> Yes. You can have multiple catch blocks inside the same try block.


Well, this has been in FPC/Delphi from the start
Ultimately handling multiple exceptions in one catch block is the whole
purpose of having exception mechanism in a language.


You can also have a single catch block with a comma separated list of
> exception types.
>

I think it's actually Pipe separated.
And is that true, that the variable specified for catching such exception
would default to a common "Exception" class?
Not available in freepascal indeed.



> Then lastly, you can even add a finally block in there too

Also not available, but people are asking :

https://bugs.freepascal.org/view.php?id=24216
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Felipe Monteiro de Carvalho]

On Mon, Jul 10, 2017 at 3:46 PM, Graeme Geldenhuys
 wrote:
> Then lastly, you can even add a finally block in there too (Java calls this
> try-with-resources).

No, that's not what try-with-resources is.

This is try-with-resources:
https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html

Any object which implements the interface AutoClosable is auto-closed
in the try, regardless of an exception happening or not.

Pascal is a little different, since it has destructors, so I guess in
Pascal we could auto-free objects in a hypotetical try-with-resources
in Pascal. Something like:

try ( stringList := TStringList.Create;
 otherObj := TSomeOtherClass.Create; )
  code here
except
  exception block, optional
end;

And any object in the () section would be auto-freed, auto-checking if
it was already created or not.

-- 
Felipe Monteiro de Carvalho
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Graeme Geldenhuys]

On 2017-07-10 14:46, Graeme Geldenhuys wrote:

You
can also have a single catch block with a comma separated list of
exception types.


Oops, typo Not a comma separated list, but a list separated by the | 
(pipe or vertical bar) symbol.


See the last example here:

  https://docs.oracle.com/javase/tutorial/essential/exceptions/catch.html


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Graeme Geldenhuys]

On 2017-07-10 13:34, Dmitry Boyarintsev wrote:

are you referring to "Catching More Than One Type of Exception with One
Exception Handler" in
https://docs.oracle.com/javase/tutorial/essential/exceptions/catch.html


Yes. You can have multiple catch blocks inside the same try block. You 
can also have a single catch block with a comma separated list of 
exception types.


Then lastly, you can even add a finally block in there too (Java calls 
this try-with-resources).


So putting those together, it looks like this:


https://docs.oracle.com/javase/tutorial/essential/exceptions/putItTogether.html

Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Sven Barth via fpc-pascal]

Am 10.07.2017 13:19 schrieb "Michael Van Canneyt" :
>
>
>
> On Mon, 10 Jul 2017, Felipe Monteiro de Carvalho wrote:
>
>> On Mon, Jul 10, 2017 at 1:08 PM, Michael Van Canneyt
>>  wrote:
>>>
>>> The code is definitely not the same. In each case, it was measured.
There is
>>> a 10% performance loss.
>>
>>
>> I'd love a source on this one. I guess you mean in Free Pascal?
>
>
> Obviously.
>
> The classes unit can be recompiled to use the fgl (well, that used to be
so)
> as a basis. When using the resulting list and stringlist, there was a 10%
> performance loss. The main reason - If I recall correctly - was that the
fgl needs to resort to move() operations instead of direct assignments.

The fgl classes don't use Move(), but they have a virtual method that does
the assignment between the specialized parameters that's inherited from the
non-generic parent list type.

You might want to test with the list provided by the rtl-generics package.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Michael Van Canneyt]

On Mon, 10 Jul 2017, Felipe Monteiro de Carvalho wrote:


On Mon, Jul 10, 2017 at 1:08 PM, Michael Van Canneyt
 wrote:

The code is definitely not the same. In each case, it was measured. There is
a 10% performance loss.


I'd love a source on this one. I guess you mean in Free Pascal?


Obviously.

The classes unit can be recompiled to use the fgl (well, that used to be so)
as a basis. When using the resulting list and stringlist, there was a 10%
performance loss. The main reason - If I recall correctly - was that the fgl 
needs to resort to move() operations instead of direct assignments.


Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Michael Van Canneyt]

On Mon, 10 Jul 2017, Felipe Monteiro de Carvalho wrote:


On Mon, Jul 10, 2017 at 12:52 PM, Michael Van Canneyt
 wrote:

There is no performance improvement, rather the contrary. The generic list
works slower than the native list.


I meant that C++ templates (and maybe Pascal generics which are very
similar if I am not wrong) are faster than Java generics. Maybe it has
to do with that primitive types in Java cannot be added to generics at
all, but need to be wrapped in an object.

I also don't see why a template list would be slower than a fixed-type
one. It should be the same. Its just a copy of the same code.


The code is definitely not the same. 
In each case, it was measured. There is a 10% performance loss.


Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Felipe Monteiro de Carvalho]

On Mon, Jul 10, 2017 at 12:52 PM, Michael Van Canneyt
 wrote:
> There is no performance improvement, rather the contrary. The generic list
> works slower than the native list.

I meant that C++ templates (and maybe Pascal generics which are very
similar if I am not wrong) are faster than Java generics. Maybe it has
to do with that primitive types in Java cannot be added to generics at
all, but need to be wrapped in an object.

I also don't see why a template list would be slower than a fixed-type
one. It should be the same. Its just a copy of the same code.

Anyway C++ guys claim that templates are faster than Java generics,
I'm just repeating what I heard.

If they aren't faster, then Java has better generics, because they are
easier to use and debug.

-- 
Felipe Monteiro de Carvalho
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Michael Van Canneyt]

On Mon, 10 Jul 2017, Felipe Monteiro de Carvalho wrote:


On Mon, Jul 10, 2017 at 12:14 PM, Graeme Geldenhuys
 wrote:

* I seem to have grasped Generics in Java much easier than in FPC or
Delphi. I don't fully know why that is. Maybe the syntax, more examples etc?
Not sure.


Well, Java Generics are very limited in comparison with C++ / Object
Pascal generics (Java generics accepts only Objects never primitives),
so that's make them much simpler to use/understand of course.

Maybe Java is right and that's all we'll ever need and the performance
improvement of templates


There is no performance improvement, rather the contrary. 
The generic list works slower than the native list.


Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Michael Van Canneyt]

On Mon, 10 Jul 2017, Graeme Geldenhuys wrote:


On 2017-07-10 07:30, Michael Van Canneyt wrote:


If that is all, on the language side, I am a happy man :)


I did mention that it was purposely a small list



Let me give you a counter example why I think Java plainly sucks.

I get very depressed when I see things like this:


You do realise that you don't have to write code like that. ;-) It's 
like me showing you bad examples of Object Pascal code - there are even 
dedicated websites that does just that. :-) Just because the language 
allows for such code, doesn't mean you have to write code like that.


Saying that, I personally agree that your code example is hard to read 
at first, and I simply try avoid writing Java code like that.


You can't. The APIs this is used in can only work like this. 
They require templates, and they have no other way to work.


https://spark.apache.org/docs/latest/streaming-programming-guide.html


Some more examples of why I like Java.


Well, from your list the only thing I can see we could add 
is the catch block with multiple exception types.


The rest: I still don't see how this makes java "more modern".
Scala is more modern, that is for sure. I would not argue there.

But to each his own opinion, obviously.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Felipe Monteiro de Carvalho]

On Mon, Jul 10, 2017 at 12:14 PM, Graeme Geldenhuys
 wrote:
> * I seem to have grasped Generics in Java much easier than in FPC or
> Delphi. I don't fully know why that is. Maybe the syntax, more examples etc?
> Not sure.

Well, Java Generics are very limited in comparison with C++ / Object
Pascal generics (Java generics accepts only Objects never primitives),
so that's make them much simpler to use/understand of course.

Maybe Java is right and that's all we'll ever need and the performance
improvement of templates do not justify the added complexity and the
difficulty in debugging. But it is a big limitation, so your
comparison is not exactly fair here.

If Object Pascal had generics which accept only TObject I'm pretty
sure it would be just as easy to use and understand and debug as in
Java!

OTOH: The improved exception handling is indeed something we miss, in
particular try-with-resources.

Java has a very significant problem in my opinion: At least where I
live, Java is never utilized for any interresting projects. Only for
JavaEE with Spring+Hibernate and a little for Android (although
Android people don't care that much for Java, they want specific
knowledge of Android APIs and libraries, and dislike the Java generic
APIs). Its even surprising like: wow, such a nice framework and noone
ever does anything interresting with it o.O

It looks like that C++ and C# are utilized in much more varied and
interresting projects than Java.

-- 
Felipe Monteiro de Carvalho
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Graeme Geldenhuys]

On 2017-07-10 07:30, Michael Van Canneyt wrote:


If that is all, on the language side, I am a happy man :)


I did mention that it was purposely a small list



Let me give you a counter example why I think Java plainly sucks.

I get very depressed when I see things like this:


You do realise that you don't have to write code like that. ;-) It's 
like me showing you bad examples of Object Pascal code - there are even 
dedicated websites that does just that. :-) Just because the language 
allows for such code, doesn't mean you have to write code like that.


Saying that, I personally agree that your code example is hard to read 
at first, and I simply try avoid writing Java code like that.


Some more examples of why I like Java.

* This language feature I disagreed with for many years, until I
recently understood how Java works. Defining local variables when and 
where you need them in the code. Read up on the scope of variables to 
understand  it fully, but local variables scope is based on code blocks. 
So if you define a new variable inside { and } - it is only valid inside 
that block. The IDEs fully support this obviously and wouldn't even 
suggest such variables (code completion) outside such code blocks.


* Targeting older Java versions, even though you are using a newer 
version to compile the code.


* String support, and more specifically, Unicode string support is a
breeze to understand and use.

* The backwards compatibility, to use 10-15 year old BOM class files
without the original source code. They simply just work - as if you just 
compiled them. On the flip side, both Eclipse and IDEA can decompile 
class files back to .java files too - and they do an impressive job at 
that (that's obviously more useful if the original class file code 
wasn't run through a obfuscater).


* Try/Catch blocks where you can catch multiple exception types - 
without needing nested code blocks like Object Pascal. You can even add 
a finally block in there too - again without nested blocks.


* I seem to have grasped Generics in Java much easier than in FPC or
Delphi. I don't fully know why that is. Maybe the syntax, more examples 
etc? Not sure.


This list just scratches the surface obviously. And then, like you 
mentioned, the absolute massive and very impressive supporting libraries 
and frameworks.



Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[denisgolovan]

Please do.

And to that hero who is willing to take the effort - please post a call for 
donation in a separate thread :)

10.07.2017, 13:06, "Michael Van Canneyt" :
> On Mon, 10 Jul 2017, denisgolovan wrote:
>
>>  That's exactly what I mean - some (or major) part of public considers it a 
>> stopper for some reason :)
>>
>>  Sorry for hijacking the thread.
>
> I can add it to the list of sponsored projects on the foundation page.
>
> Michael.
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Michael Van Canneyt]

On Mon, 10 Jul 2017, denisgolovan wrote:


That's exactly what I mean - some (or major) part of public considers it a 
stopper for some reason :)

Sorry for hijacking the thread.


I can add it to the list of sponsored projects on the foundation page.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[denisgolovan]

That's exactly what I mean - some (or major) part of public considers it a 
stopper for some reason :)

Sorry for hijacking the thread.


10.07.2017, 12:43, "Santiago A." :
> El 10/07/2017 a las 11:17, denisgolovan escribió:
> It is not a matter of public image, it's a matter of usability, a "must
> have", a stopper.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Santiago A.]

El 10/07/2017 a las 11:17, denisgolovan escribió:
> Just my 50 cents.
>
> Even though I avoid using debugger at all cost, 
> I am willing to donate some money should someone start a crowd-funding effort 
> to get "modern" debugging support in Lazarus.
> That would definitely improve Lazarus/FPC public image.
>
It is not a matter of public image, it's a matter of usability, a "must
have", a stopper.

-- 
Saludos

Santiago A.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[denisgolovan]

Just my 50 cents.

Even though I avoid using debugger at all cost, 
I am willing to donate some money should someone start a crowd-funding effort 
to get "modern" debugging support in Lazarus.
That would definitely improve Lazarus/FPC public image.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Santiago A.]

El 10/07/2017 a las 1:32, Graeme Geldenhuys escribió:
> Hi,
>
> I've give a short reply here, in case others deem this off-topic. I
> always seem to end up in hot water about such stuff here. I can send
> you more details in private if need be.
>
> On 2017-07-09 22:16, Michael Van Canneyt wrote:
>> Would it be possible to give examples ?
>> Maybe there are things that can be done in Lazarus, and Pascal ?
>
> Some IDE examples I have already raised in recent weeks in the Lazarus
> forum. The Java IDE's are *way* more clever about what code you wrote
> and makes very intelligent suggestions when it discovers errors, or
> possible improvements (eg: because you are using a newer Java version
> that might have an improved solution). In Eclipse, Ctrl+1 will list
> the options, give you a tooltip hint of how the changed code will look
> (before any changes are made). Make your pick and press enter. Those
> could be fixing errors, improved language features, pull in missing
> import lines, implement getters and setters, define missing classes,
> field variables or local variables etc. The list of what is on offer
> is massive.
>
> Purely on the language side of things I love the fact that there
> is no *.h or an "interface section" in my code - why must C/C++ and
> Object Pascal duplicate that information. If I want to see a purely
> "interface" view of my code, the IDE doesn't that as standard in the
> unit Outline window.
>
> As I said, just a short list here, but I can list many more if you
> want - both IDE features and language features.
>
> Regards,
>   Graeme
>
My main complain to Freepascal is debugger.

Being unable to debug any field of an object is unacceptable in a 
modern professional environment (hint, properties with getter, let alone
with strings). It's ridiculous to use writeln() or creating dummy
variables to debug as if I were in 1980. You can add to the IDE as many
bells and whistles as you want, but without a serious debugger, no way.

-- 
Saludos

Santiago A.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Michael Van Canneyt]

On Mon, 10 Jul 2017, Graeme Geldenhuys wrote:


Hi,


Purely on the language side of things I love the fact that there is 
no *.h or an "interface section" in my code - why must C/C++ and Object 
Pascal duplicate that information. If I want to see a purely "interface" 
view of my code, the IDE doesn't that as standard in the unit Outline 
window.


If that is all, on the language side, I am a happy man :)

I think Java is a rather primitive language, 
so I had hoped for something massively impressive.


Let me give you a counter example why I think Java plainly sucks.

I get very depressed when I see things like this:

dstream.foreachRDD(new VoidFunction() {
  @Override
  public void call(JavaRDD rdd) {
rdd.foreachPartition(new VoidFunction() {
  @Override
  public void call(Iterator partitionOfRecords) {
Connection connection = ConnectionPool.getConnection();
while (partitionOfRecords.hasNext()) {
  connection.send(partitionOfRecords.next());
}
ConnectionPool.returnConnection(connection);
  }
});
  }
});

Such code is completely unreadable to me.

Compare this to the same code in Python:

def sendPartition(iter):
connection = ConnectionPool.getConnection()
for record in iter:
connection.send(record)
ConnectionPool.returnConnection(connection)

dstream.foreachRDD(lambda rdd: rdd.foreachPartition(sendPartition))

The very paragon of readability.

Or Scala:

dstream.foreachRDD { rdd =>
  rdd.foreachPartition { partitionOfRecords =>
val connection = ConnectionPool.getConnection()
partitionOfRecords.foreach(record => connection.send(record))
ConnectionPool.returnConnection(connection)
  }
}

Infinitely more readable than Java in my opinion. 
And that is what matters to me.


The Java version with all it's templates is just painful.

(And mainly the reason why I think common use of Generics or templates 
is just a plain wrong approach, but that is another story)


So in fact your mail is a relief, I thought there would be some killer
arguments why Java is better than Object Pascal...

About the IDE: there I cannot argue, there are probably many more things
that can be done in Lazarus.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Graeme Geldenhuys]

Hi,

I've give a short reply here, in case others deem this off-topic. I 
always seem to end up in hot water about such stuff here. I can send you 
more details in private if need be.


On 2017-07-09 22:16, Michael Van Canneyt wrote:

Would it be possible to give examples ?
Maybe there are things that can be done in Lazarus, and Pascal ?


Some IDE examples I have already raised in recent weeks in the Lazarus 
forum. The Java IDE's are *way* more clever about what code you wrote 
and makes very intelligent suggestions when it discovers errors, or 
possible improvements (eg: because you are using a newer Java version 
that might have an improved solution). In Eclipse, Ctrl+1 will list the 
options, give you a tooltip hint of how the changed code will look 
(before any changes are made). Make your pick and press enter. Those 
could be fixing errors, improved language features, pull in missing 
import lines, implement getters and setters, define missing classes, 
field variables or local variables etc. The list of what is on offer is 
massive.


Purely on the language side of things I love the fact that there is 
no *.h or an "interface section" in my code - why must C/C++ and Object 
Pascal duplicate that information. If I want to see a purely "interface" 
view of my code, the IDE doesn't that as standard in the unit Outline 
window.


As I said, just a short list here, but I can list many more if you want 
- both IDE features and language features.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Michael Van Canneyt]

On Sun, 9 Jul 2017, Graeme Geldenhuys wrote:


On 2017-07-08 07:57, Felipe Monteiro de Carvalho wrote:

Since we are talking about language features, after learning Java I
think we could use in Pascal:


I must say, after using Java more and more in recent months, it starts 
to show why so many developers call Delphi/Object Pascal out of date. [I 
never thought I would ever say that - I have a real soft spot for Object 
Pascal]


The Java language has some awesome features and much less typing is 
required - yet not as cryptic as C/C++. The Java IDEs (primarily Eclipse 
and IntelliJ IDEA) also blow Lazarus and MSEide out of the water - but 
then they have a ton more resources at their disposal). Either way, 
those IDEs are a real pleasure to work with, and have so many programmer 
friendly features.


Would it be possible to give examples ?
Maybe there are things that can be done in Lazarus, and Pascal ?

I'm doing some work in a Java environment  myself lately, and I must 
say I have not noticed anything of these 'language features'. 
Lots of useful libraries, yes.  There I will not argue.


Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Graeme Geldenhuys]

On 2017-07-08 07:57, Felipe Monteiro de Carvalho wrote:

Since we are talking about language features, after learning Java I
think we could use in Pascal:


I must say, after using Java more and more in recent months, it starts 
to show why so many developers call Delphi/Object Pascal out of date. [I 
never thought I would ever say that - I have a real soft spot for Object 
Pascal]


The Java language has some awesome features and much less typing is 
required - yet not as cryptic as C/C++. The Java IDEs (primarily Eclipse 
and IntelliJ IDEA) also blow Lazarus and MSEide out of the water - but 
then they have a ton more resources at their disposal). Either way, 
those IDEs are a real pleasure to work with, and have so many programmer 
friendly features.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Graeme Geldenhuys]

On 2017-07-06 17:52, Marco van de Voort wrote:

''' already has meaning, you'll see that


The 3 quotes were simply an idea. You correctly identified that it is 
already used is some special cases, so then simply replace it with some 
other unique syntax that is not used yet. As Z505 mentioned, even the 
back-tick symbol should be a good option, and not used by Object Pascal 
syntax yet. For simpler typing, seeing as not all keyboard layouts seem 
to have the back-tick readily available, maybe the quote-quote could be 
used - as far as I know Object Pascal doesn't use that yet. But if I had 
to choose between the two, I would opt for the back-tick as it is more 
clearly distinguishable.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Felipe Monteiro de Carvalho]

> Language features like this is what increases productivity.

Indeed {$INCLUDESTRINGFILE file} looks like a great solution for this.

Since we are talking about language features, after learning Java I
think we could use in Pascal:

1> Default methods in interfaces (implementation multiple-inheritance,
would be extremely useful in Lazarus)

2> Try with resources like in Java

-- 
Felipe Monteiro de Carvalho
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[noreply]

On 2017-07-06 09:13, Graeme Geldenhuys wrote:

Ever had a problem like this?  You have some SQL, say:

SELECT Customers.CustomerName, Orders.OrderID
FROM Customers
FULL OUTER JOIN Orders
ON Customers.CustomerID = Orders.CustomerID
ORDER BY Customers.CustomerName;


and you want to add that SQL to the SQL property of a query at
runtime. You end up either having to turn this into a string like
this:

'SELECT Customers.CustomerName, Orders.OrderID' +
'FROM Customers' +
'FULL OUTER JOIN Orders' +
'ON Customers.CustomerID = Orders.CustomerID' +
'ORDER BY Customers.CustomerName;'

or manually in each line like this (oh please NEVER do this!):

FDQuery1.SQL.Add('SELECT Customers.CustomerName, Orders.OrderID');
FDQuery1.SQL.Add('FROM Customers');
FDQuery1.SQL.Add('FULL OUTER JOIN Orders');
FDQuery1.SQL.Add('ON Customers.CustomerID = Orders.CustomerID');
FDQuery1.SQL.Add('ORDER BY Customers.CustomerName;');


Now this has normally not been much of a problem for me, because part
of tiOPF's support tools, there is a tool name tiSQLEditor  that does
bi-directional conversions for you - to and from quoted strings for
SQL. And even straight from/to the clipboard. This tool has been
around for 17+ years. But why must this be a tool problem or a IDE
problem? Why can't the Object Pascal language solve this for us!

[the following part quoted from a online discussion by somebody else -
I fully agree with his thoughts though]

Imagine if FPC had type inference and multi-line strings, neither very
exotic features. The code then becomes:

=
var query := '''SELECT Customers.CustomerName, Orders.OrderID
FROM Customers
FULL OUTER JOIN Orders
ON Customers.CustomerID = Orders.CustomerID
ORDER BY Customers.CustomerName;'''

FDQuery1.SQL.Add(query);
=


Easier to read, easier to edit, no need for a IDE wizard or external 
tools.


Language features like this is what increases productivity. But
unfortunately it seems we all rather rely on a specific tool or IDE to
improve our productivity - thus also locking us into using those tools
only.


Regards,
  Graeme


This multiline string issue also helps with HTML:

s := '' +
   '' +
   '' +
   '' +

Instead it should be a multiline string:

s := '''
  



'''

There is also the backquote character, as an option..
`some string
on multiple
lines`


GoLang has multiline strings that work pretty good. AFAIR php has them 
too, especially for html work - but that is likely because PHP is for 
web programming and needed that feature more than Pascal did, so the 
strong need caused them to implement it more than other langauges.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Sven Barth via fpc-pascal]

Am 06.07.2017 23:34 schrieb "Graeme Geldenhuys" <
mailingli...@geldenhuys.co.uk>:
>
> On 2017-07-06 20:07, Dmitry Boyarintsev wrote:
>>
>> The thread of discussion:
>> http://lists.freepascal.org/pipermail/fpc-devel/2016-February/036709.html
>
>
>
> Thanks for the link. Seems this topic has already been discussed a year
and a bit ago.
>
> Anybody know if there was any movement on the $IncludeString idea?

See my message from yesterday night. :)

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Michael Van Canneyt]

On Thu, 6 Jul 2017, Sven Barth via fpc-pascal wrote:


On 06.07.2017 16:13, Graeme Geldenhuys wrote:

Imagine if FPC had type inference and multi-line strings, neither very
exotic features. The code then becomes:

=
var query := '''SELECT Customers.CustomerName, Orders.OrderID
FROM Customers
FULL OUTER JOIN Orders
ON Customers.CustomerID = Orders.CustomerID
ORDER BY Customers.CustomerName;'''

FDQuery1.SQL.Add(query);
=


Easier to read, easier to edit, no need for a IDE wizard or external tools.


Completely ignoring the type inference which I'm definitely not a fan of
- at least not in Pascal: In my opinion it would be better to improve
and finalize the $IncludeStringFile patch from issue #25536 (
https://bugs.freepascal.org/view.php?id=25536 ).


Sven,

What stops us from applying the patch ?
It has been in Mantis for ages.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Graeme Geldenhuys]

On 2017-07-06 20:07, Dmitry Boyarintsev wrote:

The thread of discussion:
http://lists.freepascal.org/pipermail/fpc-devel/2016-February/036709.html



Thanks for the link. Seems this topic has already been discussed a year 
and a bit ago.


Anybody know if there was any movement on the $IncludeString idea?

Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Mark Morgan Lloyd]

On 06/07/17 20:00, Sven Barth via fpc-pascal wrote:

On 06.07.2017 16:13, Graeme Geldenhuys wrote:> Imagine if FPC had type inference and multi-line strings, neither very> 
exotic features. The code then becomes:> > => var query := '''SELECT 
Customers.CustomerName, Orders.OrderID> FROM Customers> FULL OUTER JOIN Orders> ON Customers.CustomerID = 
Orders.CustomerID> ORDER BY Customers.CustomerName;'''> > FDQuery1.SQL.Add(query);> 
=> > > Easier to read, easier to edit, no need for a IDE wizard or external 
tools.
Completely ignoring the type inference which I'm definitely not a fan of- at 
least not in Pascal: In my opinion it would be better to improveand finalize 
the $IncludeStringFile patch from issue #25536 
(https://bugs.freepascal.org/view.php?id=25536 ).It has the advantage that it 
doesn't change the language and that theinclude file can be viewed 
independently with an appropriate syntaxhighlighter (especially with more 
complex SQL statements - to stick withyour example - that is something that I'd 
really welcome).Of course it has the disadvantage that one can't easily add 
variables,but for things like this one can always pass the included string 
toFormat() and friends which in my opinion would be more cleaned up anyway.


Some sort of heredoc approach would seem reasonable and I think it might 
be worth noting the PostgreSQL way:


$$Dianne's horse$$
$SomeTag$Dianne's horse$SomeTag$

$function$
BEGIN
RETURN ($1 ~ $q$[\t\r\n\v\\]$q$);
END;
$function$

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Sven Barth via fpc-pascal]

On 06.07.2017 16:13, Graeme Geldenhuys wrote:
> Imagine if FPC had type inference and multi-line strings, neither very
> exotic features. The code then becomes:
> 
> =
> var query := '''SELECT Customers.CustomerName, Orders.OrderID
> FROM Customers
> FULL OUTER JOIN Orders
> ON Customers.CustomerID = Orders.CustomerID
> ORDER BY Customers.CustomerName;'''
> 
> FDQuery1.SQL.Add(query);
> =
> 
> 
> Easier to read, easier to edit, no need for a IDE wizard or external tools.

Completely ignoring the type inference which I'm definitely not a fan of
- at least not in Pascal: In my opinion it would be better to improve
and finalize the $IncludeStringFile patch from issue #25536 (
https://bugs.freepascal.org/view.php?id=25536 ).
It has the advantage that it doesn't change the language and that the
include file can be viewed independently with an appropriate syntax
highlighter (especially with more complex SQL statements - to stick with
your example - that is something that I'd really welcome).
Of course it has the disadvantage that one can't easily add variables,
but for things like this one can always pass the included string to
Format() and friends which in my opinion would be more cleaned up anyway.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Dmitry Boyarintsev]

On Thu, Jul 6, 2017 at 10:27 AM, Marcos Douglas B. Santos 
wrote:

> That would be very, very nice.
> And instead of using [ " ' sql ' " ] would be better to use just [ " sql "
> ].
>

The thread of discussion:
http://lists.freepascal.org/pipermail/fpc-devel/2016-February/036709.html
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Bernd Oppolzer]

Am 06.07.2017 um 18:32 schrieb Andreas:


For this reason I would be against this implementation. Maybe taking 
away the need for the + sign at the end of the line. The strings are 
concatenated until a semi-colon or other symbol is encountered


This is what the (new) Stanford Pascal compiler does:

program TESTLSTR ( OUTPUT ) ;

var ZEILE : array [ 1 .. 200 ] of CHAR ;
I : INTEGER ;

begin (* HAUPTPROGRAMM *)
  ZEILE := ''
   ''
   ''
   ''
   '' ;
  WRITELN ( ZEILE ) ;
  MEMSET ( ADDR ( ZEILE ) , 'b' , 200 ) ;
  WRITELN ( ZEILE ) ;
  for I := 1 to 200 do
ZEILE [ I ] := '=' ;
  WRITELN ( ZEILE ) ;
end (* HAUPTPROGRAMM *) .

that is: long strings may be concatenated simply by closing
the string constant on one line and reopening it on the next line.

http://bernd-oppolzer.de/job9.htm

HTH, kind regards

Bernd

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Marco van de Voort]

In our previous episode, Graeme Geldenhuys said:
> 
> Imagine if FPC had type inference and multi-line strings, neither very 
> exotic features. The code then becomes:
> 
> =
> var query := '''SELECT Customers.CustomerName, Orders.OrderID
> FROM Customers
> FULL OUTER JOIN Orders
> ON Customers.CustomerID = Orders.CustomerID
> ORDER BY Customers.CustomerName;'''


''' already has meaning, you'll see that 

var s : ansistring;
begin
  s:='''text''';
end.

already compiles now.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Karoly Balogh (Charlie/SGR)]

Hi,

On Thu, 6 Jul 2017, Graeme Geldenhuys wrote:

> On 2017-07-06 15:35, Karoly Balogh (Charlie/SGR) wrote:
> > But sure, web devs are well known for their productivity... :P
>
> Just in case you thought I was a web developer - far from it!
>
> Anyway, the idea was just that - an idea (and possibly an improvement)
> on an age old problem. I have no means or skills to implement something
> like that in FPC. But I thought it might be worth a discussion. I like
> to think outside the box every now and again - most of my projects show
> that.

Sure, we should be free to discuss such proposals, nothing wrong with
that. I just stated my opinion, but that shouldn't stop discussion in any
way. :)

Charlie
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Andreas]

Graeme, I am a big fan of your messages. You have many good ideas and I 
sometimes read a theme that I am not interested in just to see your 
response.


In this case however I think you are wrong. Pascal has fantastic 
inherent type and error checking in its structure. It would be wrong to 
have an editor that can introduce unwanted errors. Just one way that I 
can see potential problems in you code style is the line end. Not every 
string is a SQL text which is very flexible in it's interpretation. 
Other string may want one or more spaces between the last symbol on the 
top line and the first on the second, today the editor normally strips 
these spaces away. If they are left in, they are spaces that visually I 
can not determine just by looking at the code. A mess.


For this reason I would be against this implementation. Maybe taking 
away the need for the + sign at the end of the line. The strings are 
concatenated until a semi-colon or other symbol is encountered



On 06/07/2017 11:13, Graeme Geldenhuys wrote:

Ever had a problem like this?  You have some SQL, say:

SELECT Customers.CustomerName, Orders.OrderID
FROM Customers
FULL OUTER JOIN Orders
ON Customers.CustomerID = Orders.CustomerID
ORDER BY Customers.CustomerName;


and you want to add that SQL to the SQL property of a query at 
runtime. You end up either having to turn this into a string like this:


'SELECT Customers.CustomerName, Orders.OrderID' +
'FROM Customers' +
'FULL OUTER JOIN Orders' +
'ON Customers.CustomerID = Orders.CustomerID' +
'ORDER BY Customers.CustomerName;'

or manually in each line like this (oh please NEVER do this!):

FDQuery1.SQL.Add('SELECT Customers.CustomerName, Orders.OrderID');
FDQuery1.SQL.Add('FROM Customers');
FDQuery1.SQL.Add('FULL OUTER JOIN Orders');
FDQuery1.SQL.Add('ON Customers.CustomerID = Orders.CustomerID');
FDQuery1.SQL.Add('ORDER BY Customers.CustomerName;');


Now this has normally not been much of a problem for me, because part 
of tiOPF's support tools, there is a tool name tiSQLEditor that does 
bi-directional conversions for you - to and from quoted strings for 
SQL. And even straight from/to the clipboard. This tool has been 
around for 17+ years. But why must this be a tool problem or a IDE 
problem? Why can't the Object Pascal language solve this for us!


[the following part quoted from a online discussion by somebody else - 
I fully agree with his thoughts though]


Imagine if FPC had type inference and multi-line strings, neither very 
exotic features. The code then becomes:


=
var query := '''SELECT Customers.CustomerName, Orders.OrderID
FROM Customers
FULL OUTER JOIN Orders
ON Customers.CustomerID = Orders.CustomerID
ORDER BY Customers.CustomerName;'''

FDQuery1.SQL.Add(query);
=


Easier to read, easier to edit, no need for a IDE wizard or external 
tools.


Language features like this is what increases productivity. But 
unfortunately it seems we all rather rely on a specific tool or IDE to 
improve our productivity - thus also locking us into using those tools 
only.



Regards,
  Graeme



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Graeme Geldenhuys]

On 2017-07-06 15:35, Karoly Balogh (Charlie/SGR) wrote:

But sure, web devs are well known for their productivity... :P


Just in case you thought I was a web developer - far from it!

Anyway, the idea was just that - an idea (and possibly an improvement) 
on an age old problem. I have no means or skills to implement something 
like that in FPC. But I thought it might be worth a discussion. I like 
to think outside the box every now and again - most of my projects show 
that.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Karoly Balogh (Charlie/SGR)]

Hi,

On Thu, 6 Jul 2017, Graeme Geldenhuys wrote:

> Imagine if FPC had type inference and multi-line strings, neither very
> exotic features. The code then becomes:
>
> =
> var query := '''SELECT Customers.CustomerName, Orders.OrderID
> FROM Customers
> FULL OUTER JOIN Orders
> ON Customers.CustomerID = Orders.CustomerID
> ORDER BY Customers.CustomerName;'''
>
> FDQuery1.SQL.Add(query);
> =
>
> Easier to read, easier to edit, no need for a IDE wizard or external
> tools.
>
> Language features like this is what increases productivity.

Stuff like this looks almost as bad to me, as PHP intermixed with HTML and
Javascript. But sure, web devs are well known for their productivity... :P

(And I'm quite conservative on such things, so ignore me. :) )

Charlie
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Marcos Douglas B. Santos]

On Thu, Jul 6, 2017 at 11:13 AM, Graeme Geldenhuys
 wrote:
>
> Imagine if FPC had type inference and multi-line strings, neither very exotic 
> features. The code then becomes:
>
> =
> var query := '''SELECT Customers.CustomerName, Orders.OrderID
> FROM Customers
> FULL OUTER JOIN Orders
> ON Customers.CustomerID = Orders.CustomerID
> ORDER BY Customers.CustomerName;'''
>
> FDQuery1.SQL.Add(query);
> =
>
>
> Easier to read, easier to edit, no need for a IDE wizard or external tools.
>
> Language features like this is what increases productivity. But unfortunately 
> it seems we all rather rely on a specific tool or IDE to improve our 
> productivity - thus also locking us into using those tools only.

That would be very, very nice.
And instead of using [ " ' sql ' " ] would be better to use just [ " sql " ].

Best regards,
Marcos Douglas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal