Hello,
everything below is imho as usual... ;)
Florian Klaempfl schrieb:
(<joke>wow, that's a long "currently", and a lot of 1-2 weeks</joke>)? And my best guess is that interfaces are
>>not part of the 2.0 plan (even bug reports and fixes I made were >>completely ignored, just like interfaces aren't part of the >>2.0 goal).
Interfaces are part of 2.0 but mainly to be dephi compatible.
Does that mean that the incompatibilites/bugs for "as", "is", reference counting (assuming that the current behaviour is as ml says), see bug list, will be fixed for 2.0 or not?
Features being developed now are: MI interfaces 90% (MI=multiple inheritance) Inclasses 15% (embedded classes) foreach 0% (well, we know you hate it)
It's a useless statement if used for arrays, enumerations etc. It blows up the language for no gain. I really wonder what people would say about a foreach which iterates through arrays in random order. I guess 90 per cent of the programs break though it would be completely legal :)
I don't think it'd be a major shortcoming to just define the iteration order for special types (arrays).
Similar to that the high() operator for sets (discussed some time ago). Or enumerations that are implicitely ordered.
E.g.
type
shapes = (circle, box);and circle < box evaluating to true, which doesn't really make sense either.
And D9 does have them.
It makes some use for containers like maps however those aren't native types in pascal.
Syntactic sugar, and could be available for classes which implement a certain interface as well (as in other languages). This implementation defines a "natural" guaranteed iteration order, which is documented.
I would not see a problem with that.
An array is more or less an ordered set of elements (elements having a strict natural ordering imposed by the indices, or, position in the array), or another example, in a class called TLinkedList I'd expect to get an iteration order according to the element order, and if I used it as a Collection, I'd expect no natural ordering (the name in this case serving as documentation).
Similar to your example where you wouldn't expect any ordering in a Map if you iterated over it since it simply does not have a natural ordering.
and some other things which are mostly done, but my best guess is that will be
pascal-off or too-heretic-like and used by me only.
History has shown that using incompatible solutions isn't that good. Simply because people prefer to compile their sources with different compilers.
<provocative>
OBJFPC and FPC mode are already incompatible to e.g. DELPHI and TP mode or not? These things are not breaking backwards compatibility within that particular mode or not?
=) </provocative>
Regards, Thomas
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
