[fpc-pascal] "is"

[Marco van de Voort]

> Marco van de Voort schrieb:
> >>That there are different types of iterators (forward, backward, and 
> >>random access, readonly, writeable, ...) is definitely a feature of a 
> >>specific iterator imo.
> > 
> > I'm more thinking on different properties. E.g. on address, on name etc. 
> 
> I don't understand that remark right now, but it sounds interesting 
> (maybe because it's late). Care to explain that briefly? (Or give a 
> reference)

You were thinking too implementation specific. A container object is something
with access to other containers, no order enforced. So it can multiple orders.

E.g. if your object is a clientdataset or so, you can simply select a
different index, and iterate over a different field of your business object.
 
> > I don't buy that kind of arguments. This is Pascal, not Matlab. You
> > need to have a general idea about is what happening, and knowledge about
> > typing is a fundament of a strongly typed language.
> 
> I don't agree to this argument that this needs to reflect in the syntax 
> (your argument is "this is Pascal and that's it"). 

No it isn't. The argument is "This is Pascal, and you are expected to have
at least a vague idea about how it works, and it is strongtyped so you
are expected to at least grasp the idea of typing"

> The type of a container is the specification after the double colon,
> not the loop structure/syntax.

Trying desperately to make lots of types orthogonally, even though their
types are different, is a standard trick to make a language easy for
non-programmers. It tries to hide the typing. This is insane for a language
as pascal.

> > IMHO this time to find arguments to justify something stupid as for..each
> 
> You are right in these aspects; I'm not the person who cares much about 
> that "foreach" either. That means that I can happily live without it and 
> don't care about this syntax which is lacking usefulness, so I accept 
> and actually agree to this decision in the end.

Good. I also don't exclude anything in the future, but 

1) as discussed there is no pressing reason because it is so useful to 
	implement it\
2) there is to my knowledge zero existing codebase that uses it. 
3) .NET compability is no reason.

However e.g. in the unlikely event that a massive userbase would exchange
their D6/D7 for D2005, we might eventually have to.

Pretty much the same story as dynamic array. At a certain point, the
workarounds don't outweigh the aversion anymore.