> If the new features conform to the readability That heavily depends upon which patterns are known to reader. We all are patterns recognizers.
And today world is very different. In my example sketch, the calling like "Data.Filter( _.TotalSale > 20 )" is concise and easy to understand. Okay, given your heavy Pascal background you would stumble because you would see the thing between bracket as an unbelievable heresy. For people without Pascal background that would be easy to read. At least easier than scrolling into 3 different functions probably belonging to different objects that would implement the same idea in traditional imperative way. Generics are the ease of reading ? i saw a lot of posts calling Boost and "Modern C++ Programming" nothing else than perversion. And the enigma of generics-related compiling error messages are but a common point. But surely remembering single TList<T> is easier than remembering dozen of specialized TLists. It is all about scale and experience. And we are now recognizing larger blocks of code, than in seventies. Atoms are larger today. Can closures be abused ? Easily. Can generics be abused ? easily. Can pointers be abused? For sure. Strings ? After i saw the tutorial(sic!) on database access, that compared word (two bytes) values via "IntToHex(value, 2) = string-constant" i am sure they easily can. When you think about ease to read i believe you should compare to values. * How easier would be code to read when the feature used properly ? * How harder code would be to read when the feature is misused ? Frankly, i don't know what weights should those values have, but i tend to believe 1st is more important. You can always make spaghetti copy-pasted code with anything. 5 lines anonymous functions are hard to debug and separate from surrounding code. 10 lines ones would be nightmare. 1-2 liners are heavily simplifying reading, where they can be applied. > and ease-of-compiling principles Generics are one more indirection layer for compiler to care about. They are not simplifying compiling. And they make dynamic modules like Delphi BPLs no more self-contained. Objects are not easying compiler - now compiler should care about hidden Self parameter and generate different code for seemingly the same function, if it is method or detached function. And i did not mentioned viortual methods and properties yet. Ref-counted interfaces are even more burden. Dynamic arrays and strings are not easying compilation - they require a lot of hidden "compiler magic" in each statement using them. Supporting multiple platforms, supporting multiple Pascal extensions - it all has its price making compilation more complex. Easy compiling is good goal in the row of other ones. It has its weight but it is quite far from absolute. ----- This is funny to remember today. ;-) When i run BP 7 on 80286 computers, and then compared with size and speed of TP 5.5 - i was sure as hell that OOP is for lazy programmers, who cannot make code fast and small. And i remember comparing speed of Virtual Pascal and contemporary FPC. VP bet everything on compilation efficiency. And died. But afterall i am quitting on that. Since FPC are lacking closures i am sure here are mostly people who personally dislike them. I wanted to document why closures are good and do matter. Hopefully i did it to the extent i was able to. Surely i would not be able to convince you infinite time. So the rest of arguments would be questions of personal tastes and it would bring nothing but flamewar. Everything is compromise, with it bright and dark sides. And everything has its personal bets in every compromise. Allow me to congratulate you all with Lazarus 1.0 release and thank you with good and practical language implementation. Have a nice TimeOfDay();*) -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Delphi-s-anonymous-functions-in-Free-Pascal-tp4911527p5711060.html Sent from the Free Pascal - General mailing list archive at Nabble.com. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
