[fpc-pascal] Re: Delphi's anonymous functions in Free Pascal
AriochThe at gmail.com
Thu Aug 30 11:03:15 CEST 2012
> 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
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
But surely remembering single TList<T> is easier than remembering dozen of
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
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
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.
More information about the fpc-pascal