Re: [fpc-pascal] Food for thought - language string improvement
Am 10.07.2017 um 15:00 schrieb Sven Barth via fpc-pascal: > Am 10.07.2017 13:19 schrieb "Michael Van Canneyt" > mailto:mich...@freepascal.org>>: >> >> >> >> On Mon, 10 Jul 2017, Felipe Monteiro de Carvalho wrote: >> >>> On Mon, Jul 10, 2017 at 1:08 PM, Michael Van Canneyt >>> mailto:mich...@freepascal.org>> 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
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
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
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
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
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
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
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
On Mon, 10 Jul 2017, Sven Barth via fpc-pascal wrote: 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. home:~/fpc/rtl/objpas> grep -i move fgl.pp System.Move(Src^, Dest^, FItemSize); System.Move(InternalItems[Index+1]^, ListItem^, (FCount - Index) * FItemSize); System.Move(ListItemPtr^, ResultPtr^, FItemSize); System.Move(InternalItems[Index1]^, InternalItems[FCapacity]^, FItemSize); System.Move(InternalItems[Index2]^, InternalItems[Index1]^, FItemSize); System.Move(InternalItems[FCapacity]^, InternalItems[Index2]^, FItemSize); System.Move(Result^, (Result+FItemSize)^, (FCount - Index) * FItemSize); System.Move(CurItem^, TmpItem^, FItemSize); System.Move(Src^, Dest^, MoveCount * FItemSize); System.Move(TmpItem^, NewItem^, FItemSize); System.Move(psrc^, pdest^, LItemSize); System.Move(Src^, Dest^, FKeySize); System.Move(Src^, Dest^, FDataSize); ___ 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
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
On Mon, Jul 10, 2017 at 6:14 AM, Graeme Geldenhuys < mailingli...@geldenhuys.co.uk> wrote: > > * 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. > 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 ? ___ 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
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
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? Because I searching the web C++ developers seam all sure that templates are the 7th wonder and so fast. And in Java I am 110% certain that generics add zero performance penalty. Generics don't even exist in Java after compilation, they don't produce any different code than if you had hard-coded Object. It's just a compile type type-checking. Under the hood there is only 1 code operating on Object instances. It is backwards compatible to pre-generic Java and it can't possibly impact performance. -- 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 ___ 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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
[fpc-pascal] Food for thought - language string improvement
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 -- 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