> >> << do something with elem >> > >>end; > >>[...] > > > > True, BUT... hmm, I actually have 3 BUTS > > It is some sort of syntactic sugar, so all your but's are valid at least > in some way. Nobody ever doubted this.
Good. > > BUT 1: some form shorter syntax can be thought up for _each_ _and_ > > [...] > > > > BUT 2: The whole purpose of iterators is that you can have multiple orders > >on the same object, and get a different iterator to get a different order. > > I disagree, the main purpose of iterators is to provide uniform > iteration over containers (e.g. to use the same code to iterate over > different collections). > 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. > If you have to program differently for every container (for i := low(x) > to ..; for i := 0 to count-1 ...; etc. etc.) only makes code harder to > understand and error prone without additional gain. 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. Note that I name Matlab and not VB. Contrary to popular myth, you need to have a pretty good sense about what is happening in VB too, at least if your program is non-trivial. > Additionally if you examine code, _far_ the most applications do simple > forward (and maybe backward) iteration over a collection (also because > there are not that much collections where random access makes sense > runtime-wise). My point was that if you invent syntax, at least make it somewhat general. However that is pretty much the point of this extension. A few people knew this construct from VB, which has no sane syntax anyway, and complained about the two extra keystrokes. It has nothing to do with design or thinking about a nice, general solution. > So maybe it is feasible to enhance the syntax to the following (BNF this > time): > > foreachstatement ::= > "foreach" element "in" container ["forwards" | "backwards"] "do" > statement. foreach element in container[.interface] do statement with interface the a property that returns an interface to the iterator, one being default However this is all just trying to find justification to implement it. I brought the point up to show that the syntax wasn't really thought about, just plain copied. > *ducks into cover, awaiting flames* =) IMHO this time to find arguments to justify something stupid as for..each and MI interfaces should better be invested in researching a documenting a possible implementation for generics. At least that opens a scala in possibilities, and is not simply trying to avoid two keystrokes of typing, that could be solved with an IDE macro/template anyway. > You are right, it _is_ syntactic sugar. Never doubted it. But iterators > may be an important tool in programming which may justify inclusion into > the language. Then come with a nice library design that does iterators in a sane way. With possible extensions. Then we might have a sane talk about it. > > while lightmapiterateover(iter) do > > << do something with lightmapgetobject(iter)>> > > // no finalisation of iter necessary. > > > > Is this so bad ? I don't see the problem > > I'm not sure that I'm interpreting your code sequence correctly, but I > don't consider this design as very good either (maybe driven by > implementation considerations though) - you lost abstraction over the > container type which forces the programmer to learn the correct commands > for every type of container (which isn't too hard assuming that they are > pretty similar - but there is no real *gain* for doing that. And you > don't lose anything when you do it the other way) You might notice that the names are exactly DECAL notation with type prefixed. However decal (an interface based implementation) was painfully slow. A decal <string,objects> map is slower than a sorted tstringlist, which is already not really a performance wonder. > The finalization is a pure design issue, depending on the capabilities > of the container (thread safety, safe for container modification, ...) > which may be needed to properly release used resources. This is an option. Indeed. > Additionally you lost type safety (e.g. missing the typecast of the > retrieved object =). There is only one solution for that. Generics. Not a custom solution for every point were it might occur. > Taking all that into account there isn't much difference in typing > between the two proposals, isn't there? IMHO not in all three, since it is all invoking a template to me :) _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
