tom_at_work at gmx.at
Tue Apr 5 15:29:31 CEST 2005
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
> 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.
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
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.
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?
More information about the fpc-pascal