Re: Discriminants of tagged types

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 28 Oct 2010 01:50:51 -0700 (PDT), Maciej Sobczak wrote:

> On 28 Paďż˝, 09:53, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> Because tagged types usually represent entities that are bound to some
>>> resources
>>
>> This has nothing to do with copying. Consider a handle of a resource, e.g.
>> HWND as an example. It is bound to the resource, nevertheless it is
>> copyable.
> 
> Just like a file descriptor. Yet, there is no reason for these things
> to be polymorphic.

Nonsense. The handles must be typed. The relationships between their types
must reflect ones of the types of the target objects. Example, the handle
to an edit control must have a type derived from the type of a handle to a
window.

> Now consider a window or a file (as opposed to handle or descriptor).
> They are different from handles and descriptors in that they represent
> the target resources together with their lifetime management. That is,
> I expect that finalizing the window object leads to the window being
> closed or that finalizing the file object leads to the file being
> flushed and closed, etc. Copy operations for such types are
> meaningless.

That depends on the concrete case. There is much sense to be able to copy a
file or a graphical context.

> What would it mean to copy a file object? Should the file on disk be
> copied as well?

Yes, the file is on the disk, isn't it?

> Should the data that is still in the buffer be copied?

Yes. The data in the buffer is an implementation detail of which the file
user does not care. That is, the observable behavior shall not depend on
the implementation. If you copy a file it is copied independently on
whatever buffers be in whatever state.

> And so on. Instead of answering these questions in an unsatisfactory
> way, it is better to outlaw the dubious operation up front.

Programming is all about answering questions in unsatisfactory ways. The
goal is to minimize unsatisfaction. (:-))

>> Rather the opposite, most of container types are not copyiable [*]
> 
> Is Vector limited?

In which library? It could be or could be not. I designed unbounded arrays
not copyable.

>> most of them are very useful to derive from [**].
> 
> I don't see any justification for this.

Maybe you don't, but as a matter of fact, I derive from 3/4 of container
types I use. The container implementation provides an implementation to
adjust. It is a design tool, not an end product.

The way types (tools) are applied constitutes the types algebra. Derivation
is one of the most important operations of the algebra. That is why ideally
any type shall be inheritable.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de