Re: Generic Collection

[Simon Wright <simon.j.wright@mac.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

>> I would probably end up with a package for each, with appropriate Add
>> operations.
>> 
>> with Tuples;
>> package Tables is
>>   type Table is private;
>>   procedure Add (To : in out Table; Item : Tuples.Tuple);
>
> + some other set-theoretic operations on the containers.
>
> You meant
>
>    procedure Add (To : in out Table; Item : Tuples.Tuple'Class);
>
> of course.

Did I? Not if Tuple isn't (visibly) tagged. Why would I make it
tagged? (I don't see anything in the application use cases so far (!)
to say it should be).

If your implementation guidelines say that everything should be tagged
I'd have to ask why? (I don't believe that programming-language
inheritance is necessarily a good way of implementing application area
specialization/generalization).

>> I can't see what possible advantage you'd get from being able to
>> add a Colour to a Schema! If you make a container that can contain
>> anything you will need to have runtime checks to enforce this sort
>> of rule rather than compile-time checks.
>
> The problem is not in checks but with the design. The code reader
> has no idea of what can be done with a collection member <=> what to
> expect there <=> what can be put there. The algebra of collections
> does not tell anything about that (= about the meanings of tuples
> and the sets of). It is not yet a design.

I think we are probably agreeing here. In general
collections/containers are part of the implementation, not part of the
application; I don't think I've ever found a case where it would have
been right to show an application-level concept like Table as being
visibly a container.

>> Elsewhere in this thread you seemed
>> to scoff at this as being a concern; I think classwide programming
>> ought to be restricted to the places where it brings you an advantage
>> rather than being something that makes your life difficult.
>
> Uhm, class-wide programming above is rather about implementation of
> containers in a manner independent on what is in. This does not
> contradict in any way to problem solving, which presumes doing
> something with the things in the containers. These are just two
> different problems. So as long as nobody says anything about what
> should be done with tuples, we assume that it must be nothing. (:-))

I guess I expressed myself badly there. I was trying to make the point
I've just made above.