Re[2]: Abstract Functions

Re[2]: Abstract Functions

[ANH_VO]

Absolutely, an abstract tagged type can contain data fields. Of course, object
or variable can not be declared.

A. Vo

<< A question I could get answered by the compiler, but maybe this is less
typing: Can I have an abstract tagged type that has data fields? My
recollection of examples I've seen have not had data - just null records. >>

Re: Abstract Functions

[tmoran]

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.

Re: Abstract Functions

[Marin David Condic]

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.

Abstract Functions

[Marin David Condic]

Suppose you have a tagged type that is not abstract, but you want to provide
functions as a "template" that some inheritor is supposed to override. You
can't make the functions abstract without the tagged type also being
abstract. You might not want that because you might want data and operations
in the parent class that actually work. Is there a way to say "Here's almost
everything you need, but you have to override this function with one of your
own design..." and not have the parent be abstract? I need some way of
forcing the inheritor to provide the function and I'd prefer not to go
generic.

So far, my current answer is to provide the functions I expect to be
overriden and have them raise an exception. This keeps the inheritor from
actually using the functions, but it would be nice to have a compile-time
check that insures the inheritor has to provide the desired functions. Any
ideas?

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/

Re: Abstract Functions

[Ted Dennison]

In article <9ihnia$i8h$1@nh.pace.co.uk>, Marin David Condic says...
>
>Suppose you have a tagged type that is not abstract, but you want to provide
>functions as a "template" that some inheritor is supposed to override. You
>can't make the functions abstract without the tagged type also being
>abstract. You might not want that because you might want data and operations
>in the parent class that actually work. Is there a way to say "Here's almost

I believe you can have non-abstract primitive subprograms for abstract types.
What's wrong with doing that?

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Abstract Functions

[Marin David Condic]

That is one possible way to go. However, what I have is a working parent
type that does useful things in its own right. It would be useful to have a
way of keeping it executable, but adding one or more operations that would
require extension. Basically, if you have a type that is a few generations
down the inheritance tree and now want to add some abstract operations, the
only way to do that is make the whole tree of types abstract. I'd prefer not
to do that.

Its the sort of thing where I've gone down a chain of inheritance and said
"O.K. Now I need the user to provide me with some functions and I don't want
to make this generic." I suppose I could use pointers to functions but I've
never liked that answer.

A question I could get answered by the compiler, but maybe this is less
typing: Can I have an abstract tagged type that has data fields? My
recollection of examples I've seen have not had data - just null records.

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/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:6b_27.15423$Kf3.181711@www.newsranger.com...
> In article <9ihnia$i8h$1@nh.pace.co.uk>, Marin David Condic says...
> >
>
> I believe you can have non-abstract primitive subprograms for abstract
types.
> What's wrong with doing that?

Re: Abstract Functions

[Ehud Lamm]

Marin David Condic <marin.condic.auntie.spam@pacemicro.com> wrote in message
news:9ihs6j$k33$1@nh.pace.co.uk...
> A question I could get answered by the compiler, but maybe this is less
> typing: Can I have an abstract tagged type that has data fields? My
> recollection of examples I've seen have not had data - just null records.


Yes, you can. Indeed, so many example are "abstract tagged null record" that
many think that all these go together.

Ehud Lamm

Re: Abstract Functions

[Marin David Condic]

Thanks. I'll see if maybe I can restructure my chain of classes to use
abstract & maybe life will get better.

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/


"Ehud Lamm" <mslamm@mscc.huji.ac.il> wrote in message
news:9ihv9n$bt9$1@news.huji.ac.il...
>
> Yes, you can. Indeed, so many example are "abstract tagged null record"
that
> many think that all these go together.
>

Re: Abstract Functions

[Ted Dennison]

In article <9ihs6j$k33$1@nh.pace.co.uk>, Marin David Condic says...
>
>That is one possible way to go. However, what I have is a working parent
>type that does useful things in its own right. It would be useful to have a
>way of keeping it executable, but adding one or more operations that would
>require extension. Basically, if you have a type that is a few generations
>down the inheritance tree and now want to add some abstract operations, the
>only way to do that is make the whole tree of types abstract. I'd prefer not
>to do that.

It's been a while, but I'm pretty sure you can do an "is abstract new ...", even
if the parent type isn't abstract.

>A question I could get answered by the compiler, but maybe this is less
>typing: Can I have an abstract tagged type that has data fields? My

Yup. Beging able to have non-abstract primitive wouldn't be of much use if there
weren't some existing fields for the subprogram to operate on.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Abstract Functions

[Tucker Taft]

Marin David Condic wrote:
> 
> That is one possible way to go. However, what I have is a working parent
> type that does useful things in its own right. It would be useful to have a
> way of keeping it executable, but adding one or more operations that would
> require extension. Basically, if you have a type that is a few generations
> down the inheritance tree and now want to add some abstract operations, the
> only way to do that is make the whole tree of types abstract. I'd prefer not
> to do that.

That's not true.  Abstractness is *not* inherited.  An
abstract type can have a non-abstract parent, and vice-versa.
So you could have a useful non-abstract "grandparent" type,
an abstract immediate parent, and then a non-abstract
child of this parent.  Also remember that functions that
return the type will automatically become abstract on
inheritance, and thereby require overriding.

> 
> Its the sort of thing where I've gone down a chain of inheritance and said
> "O.K. Now I need the user to provide me with some functions and I don't want
> to make this generic." I suppose I could use pointers to functions but I've
> never liked that answer.
> 
> A question I could get answered by the compiler, but maybe this is less
> typing: Can I have an abstract tagged type that has data fields? My
> recollection of examples I've seen have not had data - just null records.

As someone else pointed out, abstract types can have as
many components as you want.  They can also have non-abstract
operations.  They can pretty much have everything a non-
abstract type has (except for non-abstract functions that
return the type).

> 
> 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/
> 
> "Ted Dennison" <dennison@telepath.com> wrote in message
> news:6b_27.15423$Kf3.181711@www.newsranger.com...
> > In article <9ihnia$i8h$1@nh.pace.co.uk>, Marin David Condic says...
> > >
> >
> > I believe you can have non-abstract primitive subprograms for abstract
> types.
> > What's wrong with doing that?

-- 
-Tucker Taft   stt@avercom.net   http://www.avercom.net
Chief Technology Officer, AverCom Corporation (A Titan Company) 
Bedford, MA  USA (AverCom was formerly the Commercial Division of AverStar:
http://www.averstar.com/~stt)

Re: Abstract Functions

[Marin David Condic]

Interesting. I could have sworn that I waved it in front of the compiler and
heard it whine about having an abstract function on a non-abstract tagged
type. You are saying that I have to derive a whole new class from the
non-abstract and tag that type as being abstract? Just goes to show one more
example of Originality Through Incompetence! :-) Maybe I'll take another
SWAG at it, but basically I found a "better" way of doing the job that
involved restructuring the class heierarchy some. Hence, now everything is
abstract until it becomes concrete. But its good to know that a solution
does exist.

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/


"Tucker Taft" <stt@avercom.net> wrote in message
news:3B53601D.1295AF39@avercom.net...
>
> That's not true.  Abstractness is *not* inherited.  An
> abstract type can have a non-abstract parent, and vice-versa.
> So you could have a useful non-abstract "grandparent" type,
> an abstract immediate parent, and then a non-abstract
> child of this parent.  Also remember that functions that
> return the type will automatically become abstract on
> inheritance, and thereby require overriding.
>

Re: Abstract Functions

[Stephen Leake]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:

> That is one possible way to go. However, what I have is a working parent
> type that does useful things in its own right. It would be useful to have a
> way of keeping it executable, but adding one or more operations that would
> require extension. 

What does that mean? How can it be both "executable" (presumably
without declaring a derived type), and "require extension" (presumably
by requiring a derived type). This seems inherently contradictory,
which may be why you are having trouble doing it :).

> Basically, if you have a type that is a few generations down the
> inheritance tree and now want to add some abstract operations, the
> only way to do that is make the whole tree of types abstract. I'd
> prefer not to do that.

Ok, make it generic.

> Its the sort of thing where I've gone down a chain of inheritance
> and said "O.K. Now I need the user to provide me with some functions
> and I don't want to make this generic." 

Ok, use pointers to functions.

> I suppose I could use pointers to functions but I've never liked
> that answer.

Ok, we've suggested all the Ada ways, and you've said "I don't wanna".
Go use C++ :).

Seriously, you need to give more detailed reasons why all these ideas
are bad.

-- 
-- Stephe