Michael Van Canneyt wrote:
On Tue, 20 Oct 2009, Paul Ishenin wrote:
Michael Van Canneyt wrote:
At least one of the reasons we never did implement for-in is the
absolutely
horrible and totally wrong idea to use classes/interfaces for this,
to which
I seriously objected.
Reading this I conclude you are against 'for-in' implementation in fpc.
No.
I can understand
for y in enumerated do
or
For y in set do
or
For Y in range do
Because this seems a natural extension of loops to enumerates (and even
then) But not ever the class-based one.
So you are not against it but you want to allow them only for the base
types?
Yes.
IMO too
I hope you understand that ppl will use them for classes anyway?
Those people should be re-educated to use iterators.
Exactly. This all start to look a bit to much like the VB iterator
magic. Where some under the hood functions (names) were used for
iterating. If you didn't declare a container with the right function
names you couldn't loop.
var
P: Pointer;
begin
for P in GetComponents(Component) do
TComponent(P).DoSomething;
end;
And what is so special in the class type?
First:
For a for loop, you are guaranteed that the loop logic behaves correctly.
A loop is equivalent to the following:
I:=StartValue;
E:=EndValue;
While I<=EndValue do
begin
// loop stuff
Inc(I);
end;
And you cannot change I manually during the loop.
You don't know this with an iterator since you depend on the implementation
of the iterator. The loop could loop forever then...
Secondly:
You promote a certain class/interface to a language feature. The
compiler then depends on the presence of a certain class with some
'known' methods in the RTL.
Both points are simply wrong from a language point of view.
Exactly. You extend a language construct with something defined with
that language (i don't know how to explain better)
It is bad enough that the second point is already so for interfaces and
even TObject, (a very serious design flaw by Borland) but extending this
even further to include actual language features such as the for loop is
2 bridges too far
as far as I'm concerned.
Especially when you can have perfectly the same functionality with
iterators.
I can see a use for using iterators in a for loop, however they should
be declared with some keyword.
Something like
type
TListIterator = iterator(TList, init_func, next_func, check_func)
function init_func: Boolean;
function next_func: <element type>
function check_func: Boolean;
end;
begin
for element in list using TListIterator do...
IMO this is more pascal than using some interface or predefined function
names.
Marc
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
