Re: Abstract Functions

["Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>]

Kool!!! I had not thought to take a non-abstract tagged record and turn it
into an abstract tagged record. That would about solve the problem by
specifying an intermediate class that the user derives from - preserving all
the workings of the root class while allowing you to specify new abstract
operations.

Thanks. I'll give that a try and see if the compiler swollows it.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


<tmoran@acm.org> wrote in message
news:qo137.175321$%i7.114223450@news1.rdc1.sfba.home.com...
> I think a fair summary is "go ahead, write what you want, it's OK".
>   In Claw.Sockets, type Socket_Type is non-abstract, with Open,
> Read, Close, etc primitives appropriate for a blocking socket.
> There's also
> type Async_Socket_Type is abstract new Socket_Type with record ...
> and various new primitives both abstract, eg,
>   procedure When_Readable(Socket : in out Async_Socket_Type) is abstract;
> and non-abstract
>   procedure When_Connect(Socket : in out Async_Socket_Type);
> The user is thus forced to supply a routine to handle incoming data
> (When_Readable) but it's optional whether he supplies a non-default
> routine to handle the initial connection event.