@Snorg

Quote:

Encapsulation and abstraction are intended to de-couple software modules - that is, to reduce dependencies between different functions and methods. What tends to happen is that programmers take shortcuts rather than respecting object boundaries - i.e. they break encapsulation it'.

That, or they take "longcuts", and waste time "objectifying" every single function call - even if in practice they're always used in specific sequence, and only once during the program runtime.

Generally, it's better leaving much of the lower level stuff as-is, and simply objectify only the "higher level stuff".

@Jupp3

Quote:

Like C++?

Similar, but C++ must be given specifications in code to compile C. And not all C is compatible.

But, C and C++ were not designed together as one complete language either.

Quote:

Also, I have seen OOP code, that's total mess, and would be WAY less so, if done in the traditional procedural way.

I recall getting a lesson JavaScript. And was reading through this code to process events. I don't know if it was common but the code looked ike a mess.

Quote:

It just seems that some people get overly obsessed over OOP, and want to enforce it on even the smallest details.

For some things I can see the merit of it. It looks cool to access things easily through objects. And also to keep private data hidden so internal changes can be made while external interfaces can remain.

Quote:

At worst, you have code do some really minor things, but still, you have to read through layers upon layers of code in different files, to have even vague idea of what it actually does.

The other thing is overhead involved in the binary code. Dynamic object allocation. Objects taking up more space with embedded methods and need to be initialised. Then the need to pass object pointer used as a kind of global variable space. Sharing object data with a method.

@Snorg

Quote:

void f (A& a)

That's yet another C++ feature I strongly dislike.

Let's say, in C I have 2 function calls:

struct mystruct;
FuncA(mystruct);
FuncB(&mystruct);

And I can clearly see that only FuncB might modify the contents, while FuncA can't. In C++ I don't really know, unless I check the code I'm calling. Or at least prototypes.

Never really understood what was the problem with pointers (*), and why someone saw it important enough to add yet another feature, that acts more or less like * const pointer.

And of course any good coders make pointers const, if the function is not modifying the data they point to (whether coding in C or C++)

@Jupp3

A pointer can be null, a reference can't.

Quote:

Jupp3 wrote: Never really understood what was the problem with pointers (*), and why someone saw it important enough to add yet another feature, that acts more or less like * const pointer. And of course any good coders make pointers const, if the function is not modifying the data they point to (whether coding in C or C++)

Careful here.

int *const ptr; // ptr is a constant pointer to int so *ptr=3; works but ptr++; does not
int const *ptr; // ptr is a pointer to a constant int so ptr++; works but *ptr=3; does not

Perhaps you mean the following as your last sentence?

"And of course any good coders specify a pointer to a const, if the function is not modifying the data they point to (whether coding in C or C++)."

I find constant pointers less useful. The C99 addition of "restrict" can help code generation quality though.

https://en.wikipedia.org/wiki/Restrict

Unfortunately, C++ did not get restrict.

@matthey

Yes, I know the difference regarding where you put the const in pointers. And that definitely was one of the things I struggled quite a bit when starting to code C. And I still struggle in putting them in correct place in english language, that's even harder than C

As for restrict pointers, they're definitely nice. And another feature that all those, who refuse to use any of the more "modern" C versions will miss.

Yes, many dismiss the updates as "allowing messy code by allowing users to introduce variables where ever they want" and those ugly C++ style comments... - but there are actually some features, that can make code run better.

And personally I am ok with C++ style comments, and variable introduction placement too, although I tend to try putting them close to the beginning of a block to keep code tidy.

The problem with the OOP implementation of BOOPSI is very simple: it's crap.

Too awkward working with it, and the message passing is also very inefficient: you have to check the message id, and if the ids are sparse values you can imagine how many comparisons have to be made until you catch the defined ones.

OOP implementation is nothing to do with C++: many OOP languages used VMTs to dispatch messages in a very efficient way. And BOOPSI inefficiency propagates to attributes accesses too, which use the taglist mechanism (so: similar problematics to check the attribute ids).

C++ has imposed nothing about how classes (objects) definition, inheritance, polymorphism have to be made. In fact, C++ wasn't the first OOP language. I personally liked and preferred Turbo Pascal (which introduce OOP very long time ago, with 5.5 version. With a SPLENDID manual talking about it, which I still appreciate).

If you compare the BOOPSI model OOP to what OOP languages provide, it's clearly evident how crappy BOOPSI is. Really crap.

@cdimauro

It wasn't crap. It was a very clever implementation bringing OOP to Amiga in an integrated way.
It allowed all sorts of neat things to be done that couldn't be done reasonably on the Amiga before.
We most likely wouldn't be having any discussion about the Amiga today without it!

But, yes I would be loath to use it today.
Certainly for some of the reasons you identified: Method IDs, tag lists.
(What is a VMT?)

Unless Windows has changed over the years (been awhile since I looked at it) all events were similarly indicated by an Event ID. I think all events had to go through the Window port as well which was an incredible pain. Certainly I can be corrected on this but to my mind they were two of the things that made Windows so very slow.

However, there are also things I don't like about the various other implementations of OOP.
Primarily that once a part sits in an inheritance line it can't be separated.
Which is where interfaces come in to some degree but it doesn't stop duplication.

This is also true where objects try to be everything.
The old notion of making two separate functions as being a better design than writing a single function that does two similar things - usually by flag - is lost.
It's understandable in that you don't want to drown programmers in objects but it is also less efficient and makes objects more complex.
It also makes it harder to make sub-features more customisable in common sets.
So different objects from different families end up doing similar things in different ways without the ability to change.

We still have a long way to go to make OOP the dream it was meant to be.
But BOOPSI was where I first learnt and has provided me with some interesting thoughts towards that. Maybe they'll end up being crap too but it's worth a shot.

@gonegahgah Quote:

gonegahgah wrote: @cdimauro It wasn't crap. It was a very clever implementation bringing OOP to Amiga in an integrated way. It allowed all sorts of neat things to be done that couldn't be done reasonably on the Amiga before. We most likely wouldn't be having any discussion about the Amiga today without it!

Sorry, but I don't find it clever. Yes, this solution allowed to make many neat things on the Amiga, but a better OOP implementation would have been possible.
Quote:

But, yes I would be loath to use it today. Certainly for some of the reasons you identified: Method IDs, tag lists. (What is a VMT?)

A Virtual Method Table: https://en.wikipedia.org/wiki/Virtual_method_table
Quote:

Unless Windows has changed over the years (been awhile since I looked at it) all events were similarly indicated by an Event ID. I think all events had to go through the Window port as well which was an incredible pain. Certainly I can be corrected on this but to my mind they were two of the things that made Windows so very slow.

That's why I don't like it as well.
Quote:

However, there are also things I don't like about the various other implementations of OOP. Primarily that once a part sits in an inheritance line it can't be separated. Which is where interfaces come in to some degree but it doesn't stop duplication. This is also true where objects try to be everything. The old notion of making two separate functions as being a better design than writing a single function that does two similar things - usually by flag - is lost. It's understandable in that you don't want to drown programmers in objects but it is also less efficient and makes objects more complex. It also makes it harder to make sub-features more customisable in common sets. So different objects from different families end up doing similar things in different ways without the ability to change.

I think that those are pretty much related to bad design decisions that coders can do even on better OOP systems.
Quote:

We still have a long way to go to make OOP the dream it was meant to be. But BOOPSI was where I first learnt and has provided me with some interesting thoughts towards that. Maybe they'll end up being crap too but it's worth a shot.

Turbo Pascal 5.5 was the first OOP system that I've leaned and heavily used, and maybe that's the reason why, after the BOOPSI was released by Commodore, I was very disappointed.

You can take a look at its guide here: https://edn.embarcadero.com/article/images/20803/TP_55_OOP_Guide.pdf
You can evaluate the differences, and see how neat and fun was to do OOP with TP5.5. The manual also goes in lower-level details, showing how the VMT worked.