an oop question

[Julieta Shem]

Alan Gauld <learn2program at gmail.com> writes:

> On 30/10/2022 14:01, Julieta Shem wrote:
>
>> I wrote the classes
>> 
>>   class Empty:
>>     ...
>>   class Pair:
>>     ...
>> 
>> (*) How to build a stack?
>> 
>> These Lisp-like sequences are clearly a stack.  
>
> That is a very important observation. A Pair IS-A Stack(sort of).
> If you had a stack you could create a Pair from it certainly.

Yes, they are the same thing --- in my mind ---, except possibly for the
user interface, names and stuff.  I do prefer to make the user think he
has something else simply because it has a different name.  It is not
the user's business to know what things are on the inside.

>> So far so good, but when it comes to building a better user interface
>> for it I have no idea how to do it.  I think one of the purposes of OOP
>> is to organize code hierarchically so that we can reuse what we wrote.
>
> One of the purposes of classes certainly. I'm not so sure it's a purpose
> of OOP. They are not the same thing. A class is a programming construct
> OOP is a programming style. Classes facilitate OOP but can be used
> outside of OOP too.

That's an interesting observation.  I like that.  Classes are one thing
and OOP is another.  Of course, at the extreme I think I will get
nowhere in trying to detect in high-precision what is OOP and what is
not.  The same for classes.  I always liked to think of C structures as
some class.  Instead of saying ``new Whatever()'', I'd say
``malloc(sizeof ...)''.  I'd then have many procedures whose first
argument were a pointer to Whatever.  They're the methods.  So the
structure Whatever si the class itself.  Is this use of C outside of
OOP?  I say it is not because my notion of OOP is that --- a way to make
objects and have methods operate on them, changing them or not.

Should I allow the non-change of objects to be OOP as well?  I think so.
To me what distinguishes functional from imperative is, for example,
imperative has side-effects.  We can take an imperative set of tools and
do not produce any side-effects (locally speaking, of course) and that
would be indisguishable from functional programming.  We can say that
imperative languages are more general than functional ones.  (That's my
non-educated guess for the moment anyhow.)

>> So I tried to make a Stack by inheriting Pair.
>
> But you said above that a Pair was a Stack. Inheritance implies an
> IS-A relationship, so Stack inheriting Pair would mean that a Stack
> was a Pair. That is not really true.

That's another interesting observation.  I do not have much
understanding of how to really think of these things and that's most
likely why I never tried to understand OOP or imperative programming.
It seems very difficult.

What I meant is that a Pair was a Stack and a Stack was a Pair.  The
reason I was creating a Stack at all was just to make the user think
it's something different --- and with more obvious names for the case
under analysis, which was the use of a stack-like data structure.

> A Stack could use a Pair (or many of them) but it is not a Pair.

Is this how I should design it?  I tried that, actually.  It seemed to
complicate my life because I had to provide to my Stack class various
other methods my Pair class already had.

> Trying to use inheritance inappropriately is one of the
> biggest (and commonest) mistakes in OOP. It invariably leads
> to complications. If in doubt use delegation instead.

What is delegation?

I think that's why I never went into OOP and imperative languages.  It
just seems bloody difficult to get anything right.  Call me stupid or
what you will, but it seems very difficult.

Any book recomendations on getting this thing mathematics-clear?

Thank you!