some problems for an introductory python test

Hope Rouselle hrouselle at jevedi.com
Wed Aug 11 08:33:40 EDT 2021


Chris Angelico <rosuav at gmail.com> writes:

> On Wed, Aug 11, 2021 at 4:18 AM Hope Rouselle <hrouselle at jevedi.xotimo> wrote:
>>
>> Chris Angelico <rosuav at gmail.com> writes:
>>
>> [...]
>>
>> >> not disagreeing... and yeah I could have thought deeper about the
>> >> answer, but I still think "notthing has been OOP" -> "yes it has, they
>> >> just didn't realize it"  was worth mentioning
>> >
>> > Oh yes, absolutely agree.
>>
>> At the same time, inside the machine nothing is OOP --- so all the OOP
>> is no OOP at all and they just didn't realize it?  This seems to show
>> that OOP is about perspective.  An essential thing for OOP is the
>> keeping of states.  Closures can keep state, so having procedures as
>> first-class values allows us to say we are doing OOP too.  (Arguments of
>> procedures are messages and function application is message passing,
>> with closures keeping a state --- and all the rest of OOP can be
>> implemented with enough such functional technology.)  In summary, OOP
>> should not be defined as some special syntax, otherwise there is no OOP
>> in ``2 + 2''.
>>
>> Having said that, I totally agree with all the nitpicking.
>
> Object orientation is a particular abstraction concept. It's not a
> feature of the machine, it's a feature of the language that you write
> your source code in. I've done OOP using IDL and CORBA, writing my
> code in C and able to subclass someone else's code that might have
> been written in some other language. [1] Central tenets of OOP
> (polymorphism, inheritance, etc) can be implemented at a lower level
> using whatever makes sense, but *at the level that you're writing*,
> they exist, and are useful.
>
> Data types, variables, control flow, these are all abstractions. But
> they're such useful abstractions that we prefer to think that way in
> our code. So, *to us*, those are features of our code. To the
> computer, of course, they're just text that gets processed into
> actually-executable code, but that's not a problem.

Total agreement.

> So I would say that (in Python) there IS object orientation in "2 +
> 2", and even in the Python C API, there is object orientation, despite
> C not normally being considered an object-oriented language.

But would you say that 2 + 2 is also an illustration of object
orientation in any other language too? 

Regarding C, I have many times said that myself.  If I wrote assembly,
I'm sure I would do my best to create things like procedures --- a label
and some bureaucracy to get arguments in and a return value out.

> ChrisA
>
> [1] And boy oh boy was that good fun. The OS/2 Presentation Manager
> had a wealth of power available. Good times, sad that's history now.

I know OS/2 only by name.  I never had the pleasure of using it.  In
fact, I don't even know how it looks.  I must be a little younger than
you are.  But not too younger because I kinda remember its name.  Was it
a system that might have thought of competing against Microsoft Windows?
:-) That's what my memory tells me about it.


More information about the Python-list mailing list