[fpc-pascal] "is"

[Thomas Schatzl]

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