Re: Problem with Booch iterators

[porton@ex-code.com (Victor Porton)]

In article <x7vheeq34xd.fsf@smaug.pushface.org>,
	Simon Wright <simon@pushface.org> writes:
> porton@ex-code.com (Victor Porton) writes:
> 
>> There are a serious misdesign of Booch iterators:
>> 
>> Declaring a record component of type Iterator'Class,
>> I get error "unconstrained subtype in component declaration".
>> 
>> So for every non-abstract collection type, a concrete iterator
>> type should be visibly declared. It also suggests that types of
>> arguments of subrountines should be changed from Iterator'Class
>> to the appropriate concrete types.
>> 
>> Simon, why you've used Iterator'Class everywhere?
> 
> Given the way the BC iterators work, I don't know what good having
> iterators in records is going to do you.

Iterator ranges, see my other message.

> I don't like the idea of unbound iterators floating around (I suppose
> though it's no worse than a Text_IO.File_Type).

What is "unbound iterator"?

> Since there are at least 3 projects using the BCs to earn themselves
> money (even if I don't see any of it, except indirectly) I won't make
> backwards-incompatible changes; and I'm reluctant to add operations
> and features, unless it can be done in a way which doesn't increase
> the footprint. I would be more inclined to remove things .. BC_Lite, I
> guess.

Changing Iterator'Class to concrete iterators in some subrountines' 
specification does not add real incompatibility: in any case passing
a wrong iterator type is a mistake.

Well, to archive good backward compatibility we need something like
Concrete_Iterator'Class in subrountines' specs. Automatic type
conversions will do the thing we need.