[fpc-devel] for-in-index loop

Michael Van Canneyt michael at freepascal.org
Mon Jan 28 14:51:36 CET 2013



On Mon, 28 Jan 2013, Paul Ishenin wrote:

> 28.01.13, 21:20, Michael Van Canneyt wrote:
>
>>> Different people see different needs in language. There is nothing bad
>>> not to use and not understand some of the language features.
>> 
>> tatata, you should always understand everything :)
>
> Very weak argument :) In your work you use system APIs and other frameworks 
> which are made in C, C++ or assembler. I believe you don't understand 
> everything and if you don't - you use the reference if needed. The same way 
> with pascal - if you don't want to learn new features then use libraries as 
> black boxes but if you need then use a reference.

I can understand the argument for libraries, but not for the programming language itself.

>>> I would use anonymouse methods in pascal - I use them in javascript
>>> when I need to perform something asynchronosly.
>> 
>> Since you can do the same with simple named methods too, I see no need
>> for creating the readibility horror that results of it.
>
> It is a readability horror when for injecting a small piece of code as 
> anonymouse method in place where it is needed you *must* declare a new named 
> method (which will no be used anywhere else) few screens up or down.

Absolutely. You have local procedures for exactly this reason.
That is what Pascal stands for.

I use Anonymous methods in Javascript too, but in the majority of cases I 
end up naming them anyway.

So I do not think the use case justifies the mutilation.

>> It offers nothing that objects didn't already have.
>
> It offers understandable memory layout without VMT.

That could have been solved with a simple "novmt' keyword just like the existing 
'packed'. There, I could have saved Embarcadero lots of valuable time with that :-)

Enough bickering; it is useless. We will not agree, no matter how many arguments are presented: 
simply because the arguments are of a metaphysical/human/whatever nature, and not technical.

Michael.



More information about the fpc-devel mailing list