@Karlos

Quote:

Karlos wrote: @agami I take it what you are alluding to is a system made of components with well defined roles and responsibilities that can be built upon to add new functionality, enhance existing features and so on. If that's true, I think perhaps "modular" better describes what you mean. Object Orientation is a paradigm supported by various languages that helps achieve modularity, but it doesn't mean modular systems have to be implemented in them.

Modular is part of it, but it only describes that there are separate modules.
It says nothing about the nature of how those modules can be used/reused.

_________________
All the way, with 68k

@kolla

Quote:

\kolla wrote: @agami First time I installed Haiku, it was on real hardware (Asus Eee Box) and the year was 2009 or so, so… I very much doubt your claim.

Fair enough
I must not have looked hard enough through the FAQ in what would've been probably around 2016/2017.

Looking at it yesterday, I was pleased to read about all the hardware support. I am now planning to install it on one of my old PCs.
Well, more like combining parts from two old PCs.

Also, I have to take issue with your comment.
I'm sure you would agree that when the first alpha of Haiku OS was release in September of 2009, the list of supported hardware would've been much more limited when compared to today. It's great that they supported an ASUS Eee Box, and that you had one or you were willing to purchase one for this purpose, but that doesn't mean that everyone could've installed it on any hardware that they already have.

So while technically it could be installed directly on (some) hardware, the narrow spec would've for all intents and purposes made it a VM-only install for most who wished to try it.

Furthermore, the Haiku OS web page even today does a poor job of communicating that the OS can be installed directly on hardware.
A simple link to Supported Hardware on the front page, right under the Installation Guide link, would make a world of difference.

_________________
All the way, with 68k

@matthey

Quote:

Linux has big advantages and big disadvantages. It's popularity is mostly due to being open source and free to use. Most OS users don't prefer it although power users and developers learn to appreciate it and users don't mind it if everything is pre-configured in one of these "specialized" Linux distros, especially if it saves them $

Tell me about it.
I have used Linux on and off (and on right now) in both professional and personal scenarios since 1996. While the mess is lesser today, it is still there.

Last weekend, I upgraded my home server from Ubuntu 20.04 to 22.04, following Ubuntu's built-in upgrade facility. It was not trouble-free. Had to do a bunch of manual trouble-shooting post upgrade, combing through logs, Googling errors, to get everything up and running again.

It also took a step backwards in remote desktop access. In 20.04 it was rock solid, but in 22.04 it does this weird thing where it randomly just switches to CAPS Lock on the host, but on the client KB I have not switched on CAPS Lock, so when I type a period (.), the output is (>). Holding Shift doesn't fix the output. CAPS Lock on and off doesn't fix it. Typing directly on the host is locked to CAPS Lock irrespective of selecting it on the host KB. A reboot fixes it.
So no native remote access until the bug is fixed.

But you are right. We somewhat learn to appreciate it. I think it kind of wears us down. And I think it's also a lack of alternatives. macOS (outside of the shrinking Hackintosh scene) is for Apple hardware. The only other consumer computing platform that can be installed on open hardware is Windows. Which I use for my gaming and VR PCs, but I'm not a fan of it as an OS for an always ON home server, though I have considered it.

_________________
All the way, with 68k

@agami

Oh come on, on amd64 there are plenty of operating systems to pick from.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@matthey

Quote:

matthey wrote: Three lines and 30kiB of code for the C++ static link library that is not shareable. All those gadgets, images, datatypes and MUI objects mentioned above are normal shared Amiga libraries. Kronos Quote: - BOOPSI leads to many potential bugs that are hard to diagnose OOP indirection makes programs more difficult to debug.

30kiB of well tested code added to the binaries size, shock horror how will I run that bloated monster when I only have 16GB of RAM !!!!!

Vs. the developer having to write 100s if not 1000s of similar but not identical lines of code spread over many classes. Each of them full of potential typos and oversights.

In everything BOOPSI you will find lines like "name = (STRPTR)tag->ti_Data" circumventing the basic type checking C offers to make it work. Or you send a Method/Message to your string-gadget that was supposed to go to the associated listview. Will compile just fine (the are all just "Object*"), may even run without crashing but for sure will not operate as planned.

Use a modern language and GUI-TK and it will either refuse to compile on a type error or do a proper conversion at run time.
It will tell you that you are trying to access a function or variable that the class does not support etc.


As I hinted earlier I did fiddle around a bit with SwiftUI in the past 2 year and as an experiment I wrote a basic version of SteamDraw in it. Sure it is just the bare minimum but it is just 20kb of sources where just the MUI-classes needed to do the same would weigh in at 70-100kb. Data handling is 20 lines (and it would be just a few more to read/write that to disk) while the MorphOS variant (using C++ features) is another 100kb or so.

-> it ain't 1990 anymore


As for all the nitpicking bout wether Linux is this or that it is pointless as:
- more people are using Linux (and Linux based OSes) as their everyday all purpose computing platform than ever did on Amiga
- more people are making a living by using Linux than ever did on Amiga
- more developer are making a living with Linux-SW than ever did with Amiga

So claiming that "Amiga" could become "the 3rd general computing platform" is like a chop-shop insisting that the will build up an old Golf to be the 1st road legal car to go over 400km/h.....

Last edited by Kronos on 01-Oct-2022 at 10:02 AM.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@kolla

There are indeed many. I've ran many different ones in VMs over the years. Most non-technical users, which is by far the majority of all users don't know what GNU is, what Linux is, or that Android and ChromeOS are derivations. They are even less likely to know that there are literally hundreds of other esoteric operating systems out there.

I'm not sure how you'd capture a segment of people that, while potentially dissatisfied with their computing experience are that incurious to be completely unaware of the alternatives that already exist.

_________________
Doing stupid things for fun...

@matthey

Quote:

BOOPSI tries to minimalise the number of indirect branches (some OOP purists would complain) and it has amazing code sharing which improves performance, reduces the computer footprint and exemplifies OOP principles

That must be why a BOOPSI method dispatch to a no-op function is dozens of times faster on 68060 than a C++ virtual function or just a vanilla function pointer dereference in C to a similarly empty function.

Except it isn't. The exact opposite is true.

_________________
Doing stupid things for fun...

@Karlos

But why would you want to capture such an audience? What would they offer in return? Computers are MUCH more fun without users, you know :)

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

I think that question is better directed at agami. It's clear he sees some potential in it.

_________________
Doing stupid things for fun...

an_overeducated_idiot Quote:

Object-oriented programming does not require inheritance. That's the most common way people see it implemented, but that's not the point. Object-oriented programming, unlike the largely "procedural" paradigms which preceded it, stresses organization of program structure around the data rather than the algorithms. A language can be object-oriented without offering classes and inheritance. For instance, Wikipedia lists Oberon* and Rust as object-oriented languages even though they do not offer classes, and Rust does not even offer inheritance. In particular, an object-oriented language does not have to have virtual function tables. If that was already understood, then never mind me.

Welcome to Amiga Neverland. Thanks for the OOP history lesson. History is often forgotten around here but obviously you thought it was important enough to create an account and make your first post here. Even the original AmigaOS seems to me to be very data focused around structures. It also has inheritance. For example, a device structure contains a library structure and has the properties of a library. Functions are usually either filling out structure data or using structure data for an algorithm. Pointers to data structures instead of pointers to data objects are common. AmigaOS library jump tables are function tables without the indirect branches. Did the AmigaOS use OOP from the beginning before BOOPSI?

Kronos Quote:

30kiB of well tested code added to the binaries size, shock horror how will I run that bloated monster when I only have 16GB of RAM !!!!! Vs. the developer having to write 100s if not 1000s of similar but not identical lines of code spread over many classes. Each of them full of potential typos and oversights.

Once code sharing is abandoned and bloat accepted, there is no return. OS scalability is a problem on bloated platforms. There shouldn't be a need for macOS and iOS or Windows and Windows Mobile. Mobile hardware can be the same architecture as desktop hardware yet these bloated OSs can't scale to even a mid footprint and a software compatibility layer is used in the case of Apple who is standardizing the hardware between mobile and desktop. ARM needs two ISAs, AArch64 and Thumb2 to scale across hardware and x86-64 has trouble scaling even into mobile power requirements. The 68k AmigaOS scales to a much smaller footprint than macOS, Windows and standard Linux distros while the upper limit is unknown but the 68060 had competitive performance to the Pentium while using significantly less resources and power. The 68k once scaled from low end embedded to high end workstation markets.

AmigaOS libraries should be well tested code too. At least it was back when there was competitive hardware. BOOPSI does not require too much code. Look at the Talk2boopsi.c example.

https://wiki.amigaos.net/wiki/BOOPSI_-_Object_Oriented_Intuition#Talk2boopsi.c

The example opens a window and has gadgets interacting directly in 143 lines of well documented and readable C code. With longer lines and C99 style comments, the main() function could probably be cut in half.

Kronos Quote:

In everything BOOPSI you will find lines like "name = (STRPTR)tag->ti_Data" circumventing the basic type checking C offers to make it work. Or you send a Method/Message to your string-gadget that was supposed to go to the associated listview. Will compile just fine (the are all just "Object*"), may even run without crashing but for sure will not operate as planned. Use a modern language and GUI-TK and it will either refuse to compile on a type error or do a proper conversion at run time. It will tell you that you are trying to access a function or variable that the class does not support etc.

C programming in AmigaOS was never the fail safe choice. It is lower level programming than most other programming languages. It provides performance without the bloat but there are tradeoffs and not everything in AmigaOS is the perfect design.

Kronos Quote:

As I hinted earlier I did fiddle around a bit with SwiftUI in the past 2 year and as an experiment I wrote a basic version of SteamDraw in it. Sure it is just the bare minimum but it is just 20kb of sources where just the MUI-classes needed to do the same would weigh in at 70-100kb. Data handling is 20 lines (and it would be just a few more to read/write that to disk) while the MorphOS variant (using C++ features) is another 100kb or so.

MUI has plenty of fluff. Does every gadget need an AREXX interface and drag and drop functionality? PPC has 50% of code fluff which is generally more than x86-64 code fluff. On the 68k, simple 2kiB programs are possible that would be 20kiB using C++, not that that is horrible. Eventually, OOP programs will stop growing after common support code is statically linked in and performance becomes a bigger concern. Still, statically linked programs aren't doing much code sharing.

Karlos Quote:

That must be why a BOOPSI method dispatch to a no-op function is dozens of times faster on 68060 than a C++ virtual function or just a vanilla function pointer dereference in C to a similarly empty function. Except it isn't. The exact opposite is true.

There are some inefficiencies from using shared libraries too. Some optimizations of owned code can't be made when using shared code like skipping tables. There is overhead to pure position independent (PC relative) code but fortunately it is lower on the 68k than most ISAs. There is room to better optimize AmigaOS code and improve compilers as well. As small of footprint as the 68k AmigaOS has, it could probably be 20% smaller overall without major changes (it is mostly compiled for the 68000 ISA using SAS/C).

@matthey
Quote:

Even the original AmigaOS seems to me to be very data focused around structures. It also has inheritance. For example, a device structure contains a library structure and has the properties of a library. Functions are usually either filling out structure data or using structure data for an algorithm. Pointers to data structures instead of pointers to data objects are common. ... Did the AmigaOS use OOP from the beginning before BOOPSI?

As an overeducated idiot, the only honest answer is that I don't know. As an overeducated idiot, that won't stop me from rambling about it.

The importance of data structures was already well-known by the time the first distinctively OO language appeared; just look for when the first textbooks on data structures appeared. So it isn't merely an awareness of data structures; rather, the design of the data structures is central to the design. Object-oriented programming focuses on what data to work with and designs the algorithms to accommodate them, whereas procedural programming focuses on what algorithms to implement, designing the data to accommodate that.

The distinctive tell of most OO languages is that you can apply the same code to different datatypes, usually with a keyword (or convention) called self or this (second paragraph at link). Thus, Rust, which has absolutely no inheritance at all and bends over backwards to keep you from using dynamic typing, still organizes by data first: the struct keyword defines a data structure, and in its implementations (the various impl sections) the first argument to a method uses the self keyword.

Contrast this to Wirth's approach to OOP in the original Oberon. It makes inheritance possible through type extension, but does not offer a self or this keyword or convention. Worse, Oberon does not bind methods to classes, so you have to engage in cumbersome silliness like repeating the object name, as in a_circle.draw(a_circle) or abandoning dynamic typing by specifying the class name you want, as in Circle.draw(a_circle). I guess the type extension and dynamic typing in the first call qualify it as object-oriented, but... ugh. Wirth and Mössenböck got it right in Oberon-2 with type-bound procedures, but rather bizarrely Wirth abandons them in the later revisions of Oberon.

From that point of view, the original AmigaOS design does not strike me as object-oriented; they were thinking in terms of, "what functionality (algorithms) do we want to offer", and the data structures followed from that. However, as with many things, the answer is less binary than fuzzy. After all, you make a great point, and in the end all windows interfaces derive from the Xerox Star and Alto. Like the Amiga, they were programmed in the definitely non-OO language BCPL, and later the modular, but probably-non-OO Mesa, while birthing Smalltalk, the quintessential OO language. And Macintosh, also a windows interface, was originally programmed in Pascal, later Obejct Pascal. In fact, I think Apple developed Object Pascal precisely to make Mac programming more reasonable.

If I may, I have a question about something you wrote. Quote:

AmigaOS library jump tables are function tables without the indirect branches.

Is that true? Consider this code (dangerous for simplicity's sake). Quote:

struct IntuitionBase * IntuitionBase; IntuitionBase = (struct IntuitionBase *) OpenLibrary("intuition.library",36)); win = OpenWindowTags(...);

Does OpenWindowTags not perform an indirect branch? It's been a decade or more since I wrote an intuition program, but my impression is that it has to look up the correct address in IntuitionBase first. I don't think I ever thought about all that too much, though.

Quote:

History is often forgotten around here but obviously you thought it was important enough to create an account and make your first post here

It's not really my first post here. I used to have another account. I keep lurking, though; I guess you could say I'm a little sick in the head. Like the dream of an old that wakes you up weeping in the middle of the night, my old experience with the Amiga keeps me coming back, even though I have no intention of owning an Amiga again. There is a benefit: some threads edify me, like this one.

Well... I also have a guilty pleasure. Unlike most of you, I enjoy mega rj mical's padding & zorram posts. I realize a lot of people dislike him, but I find him a bit amusing. (Before anyone asks, I'm not Mega, nor Franko.)

Sorry if this rambled too much.

Added later:
Here, look at this write up of the Xerox Star's interface, and compare it to the Mac's and Amiga's interfaces, where you could likewise click on an icon which represented data rather than a program. For the Amiga, the program that subsequently opened depended on the icon's .info file. That illustrates well what was indeed object-oriented about the Amiga's design, right from the beginning.

Last edited by an_overeducated_idiot on 02-Oct-2022 at 04:44 AM.
Last edited by an_overeducated_idiot on 02-Oct-2022 at 03:39 AM.

an_overeducated_idiot Quote:

As an overeducated idiot, the only honest answer is that I don't know. As an overeducated idiot, that won't stop me from rambling about it. The importance of data structures was already well-known by the time the first distinctively OO language appeared; just look for when the first textbooks on data structures appeared. So it isn't merely an awareness of data structures; rather, the design of the data structures is central to the design. Object-oriented programming focuses on what data to work with and designs the algorithms to accommodate them, whereas procedural programming focuses on what algorithms to implement, designing the data to accommodate that. The distinctive tell of most OO languages is that you can apply the same code to different datatypes, usually with a keyword (or convention) called self or this (second paragraph at link). Thus, Rust, which has absolutely no inheritance at all and bends over backwards to keep you from using dynamic typing, still organizes by data first: the struct keyword defines a data structure, and in its implementations (the various impl sections) the first argument to a method uses the self keyword. Contrast this to Wirth's approach to OOP in the original Oberon. It makes inheritance possible through type extension, but does not offer a self or this keyword or convention. Worse, Oberon does not bind methods to classes, so you have to engage in cumbersome silliness like repeating the object name, as in a_circle.draw(a_circle) or abandoning dynamic typing by specifying the class name you want, as in Circle.draw(a_circle). I guess the type extension and dynamic typing in the first call qualify it as object-oriented, but... ugh. Wirth and Mössenböck got it right in Oberon-2 with type-bound procedures, but rather bizarrely Wirth abandons them in the later revisions of Oberon. From that point of view, the original AmigaOS design does not strike me as object-oriented; they were thinking in terms of, "what functionality (algorithms) do we want to offer", and the data structures followed from that. However, as with many things, the answer is less binary than fuzzy. After all, you make a great point, and in the end all windows interfaces derive from the Xerox Star and Alto. Like the Amiga, they were programmed in the definitely non-OO language BCPL, and later the modular, but probably-non-OO Mesa, while birthing Smalltalk, the quintessential OO language. And Macintosh, also a windows interface, was originally programmed in Pascal, later Obejct Pascal. In fact, I think Apple developed Object Pascal precisely to make Mac programming more reasonable.

Interesting but as clear as mud. Still no clear definition of OOP. I don't like the definition of OOP as using an OOP language either.

an_overeducated_idiot Quote:

If I may, I have a question about something you wrote. Quote: AmigaOS library jump tables are function tables without the indirect branches. Is that true? Consider this code (dangerous for simplicity's sake). Quote: struct IntuitionBase * IntuitionBase; IntuitionBase = (struct IntuitionBase *) OpenLibrary("intuition.library",36)); win = OpenWindowTags(...); Does OpenWindowTags not perform an indirect branch? It's been a decade or more since I wrote an intuition program, but my impression is that it has to look up the correct address in IntuitionBase first. I don't think I ever thought about all that too much, though.

No indirection and no table lookup first. The library function name is used to lookup the 16 bit offset/displacement of the function at compile time during linking as I recall.

OpenWindowTagList=-606

jsr (OpenWindowTagList,a6)

---

->IntuitionBase (Library Node Structure)
Open_entry:
jmp Open // -6
Close_entry:
jmp Close // -12

...

SysReqHandler_entry: // -600
jmp SysReqHandler
OpenWindowTagList_entry: // -606
jmp OpenWindowTagList
OpenScreenTagList_entry: // -612
jmp OpenScreenTagList

There are 2 branches (jsr+jmp) to get to the function but they are both predictable. AmigaOS 4 adds the extra pointer though.

IIntuition->OpenWindowTags()

I'm not sure how this is implemented but it looks like an extra OOP step. On PPC, good luck finding a developer that knows or who can read the assembly code.

an_overeducated_idiot Quote:

It's not really my first post here. I used to have another account. I keep lurking, though; I guess you could say I'm a little sick in the head. Like the dream of an old that wakes you up weeping in the middle of the night, my old experience with the Amiga keeps me coming back, even though I have no intention of owning an Amiga again. There is a benefit: some threads edify me, like this one.

I wish Amiga was for the masses but it's for the classes now.

an_overeducated_idiot Quote:

Well... I also have a guilty pleasure. Unlike most of you, I enjoy mega rj mical's padding & zorram posts. I realize a lot of people dislike him, but I find him a bit amusing. (Before anyone asks, I'm not Mega, nor Franko.) Sorry if this rambled too much.

Mega is sometimes funny but his spamming gets annoying.

Last edited by matthey on 02-Oct-2022 at 07:00 AM.

@matthey

Quote:

matthey wrote: There shouldn't be a need for macOS and iOS or Windows and Windows Mobile. Mobile hardware can be the same architecture as desktop hardware yet these bloated OSs can't scale to even a mid footprint and a software compatibility layer is used in the case of Apple who is standardizing the hardware between mobile and desktop.

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


The rest of your post(s) is of similar "quality" so I won't bother.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@matthey

Sometimes you seem like you know what you are talking about and other times you squander that credibility.

An AmigaOS library call is by jsr followed by some additional table based indirection (a computed goto). There's no more more predictability here than a C++ method call:

1. The library base address can be anywhere.
2. The offsets in the table can be changed by various dubious means.

Assuming that best case for the above and that the address and offsets are invariant at runtime, it's not radically different to a C++ virtual function call. Substitute the library for a class instance and what happens? You have a function table. The only difference to the LVO case is in how that table is used.

The table is shared by all instances of the class and lives at a single location, rather like your LVO. The address of the function implementation is at a given offset in the table. This is loaded and jumped to. So the setup here, depending on the compiler, can be reduced to an lea to dereference the table and a jsr to the function address. That's only one jump to predict. The explicit trade off is that your table access will look like data read so the maximum performance of this mechanism is dependent on the section of the function table being in the cache for the dereference step. That said, your data cache is a lot bigger than your branch entry cache.

Finally, add to this that only virtual functions behave this way. For most classes, methods will behave exactly like regular C functions and most of the smaller ones are inlined out of existence.

Last edited by Karlos on 02-Oct-2022 at 08:54 AM.

_________________
Doing stupid things for fun...

@matthey

Quote:

Still no clear definition of OOP. I don't like the definition of OOP as using an OOP language either.

I can't tell if you are being disingenuous or not, but giving the benefit of the doubt, I'd say this is fair because there isn't a "single clear definition of OOP". It's a software paradigm that covers a wide range of principles. A language can be said to be OO if it makes those principles easy to use.

Let's start at the beginning. Imperative Programming. You give direct instructions to the machine, linearly, with a bit of decision based branching here and there (jumps, loops etc). Good examples of languages that typically follow this paradigm include:
- Assembler
- Early BASIC dialects
- Shell scripting / batch processing

Very soon you realise that common code can be put into one place that can be called from elsewhere and you have subroutines and functions. You are now dealing with Procedural Programming. Code is organised into small units that are called with zero or more parameters and can optionally return a result. Variables inside the those units are distinct from the overall state. Good examples of languages that typically follow this paradigm include:

- C
- Most BASIC dialects
- Most scripting languages

You can still write procedural code in the earlier languages but they might not make it that easy to do so without more discipline on your part. For example, in assembler there may not be any enforced calling convention. Where do parameters go? There are conventions you can follow dictated by good practise, but in essence, you can do whatever you like. You are only forced to follow conventions for using functions other people have written.

You will also note that Procedural Programming is not a distinct set from Imperative Programming. The code inside any function or subroutine is often simple imperative code.

Most procedural programming languages at this stage also have some notion of types. These can be simple machine-mappable entities like integers and floating point but generally some notion of user defined types exist, i.e. data structures and records. Code begins to become organised around the use and management of these user-defined types.

Beginning with a simple C structure and some functions we have that manage it is where we begin to start thinking along Object Oriented lines. One of the first things that most OO languages tend to do is to make that relationship - the data structure and the functions that operate on it, into a single unit, the "class". The syntax varies from language to language but ultimately the functions and structure are merged. You will generally no longer see calls of the form SetUserName(user, name), it'll be something like user->SetUserName(name). As has been described earlier in the thread, there is usually a hidden first parameter such as "this" or "self" that points at the actual instance the function is being called for. We tend to start referring to the data and functions as "properties" and "methods" respectively at this point.

We could stop here and at the very least call this the Type Oriented paradigm, something of a newly defined term to describe languages that implement this level combination but don't go that much further. However, most OO languages do go further.

The next idea tends to be one of restricting who can directly interact with the data in our Type and by which means. For a C structure, any code that can see the definition of the structure can change any element in it directly. It doesn't have to be one of our carefully written functions that does it. We arrive at data hiding (sometimes called encapsulation, though I'd argue it's just an element of encapsulation). Some languages add access levels to both the properties and methods of a Type. "Private" properties cannot be directly accessed from outside (at least within the rules of the language) and common code to do things that you only want to be called from other methods of the Type can be declared private too. By now the Type has some degree of autonomy and can only be interacted with and modified by the methods it exposes as "public".

A quick recap at this point - ultimately the methods of our Types in our programming languate are usually realised as functions and as such the language is still within the intersection of Procedural Programming. Equally for many languages those functions are often still written along Imperative Programming lines too.

At this stage, we begin to realise that the set of public methods one Type has may be a match for a related Type and so on. For example a File, a URL and a Book can all be opened for reading. We arrive at the concept of "interfaces".

An interface describes a set of methods that any implementor of that interface must provide. It doesn't mandate how any given implementor works, only the name and form of the methods it has. Almost all languages that support interfaces as a concept allow any custom Type to realise zero to many interfaces at once.

The interface provides a strong layer of abstraction. Code can now be written that has visibility of an interface only, interact with any Type implementing that interface using the interface methods and not actually need to know anything about the specific Type. We may even envisage partial realisations of interfaces by a Type that cannot be used directly but forms the basis of another Type that can, by completing the interface. This "interim" Type becomes something abstract. You could envisage an interface like IFileSystemObject that has most of the methods implemented by an abstract Type FileSystemObject that leaves a handful of the methods unimplemented. This Type is then extended into new Types that complete the interface, such as DirectoryObject, FileObject, LinkObject etc.

Languages supporting this include:
- Go
- Rust
- All "OO" languages.

We have now introduced the idea of Type extension, also called Inheritance. The final frontier of this progression is to realise that Types can be grouped into taxonomies in various ways. The ability to have interfaces to define the contract as to how something is used, along with the ability to implement zero to many interfaces per Type, have Types that are abstract or concrete and Types that can extend and/or redefine aspects of other Types leads to the classic idea of an OOP. All languages described as OO support the idea of inheritance. There are ideas around whether a Type can inherit from one or more parent Types that vary from language to language, but this model of gradual refinement or enhancement by extension of types is common to all.

A language that directly facilitates, through it's syntax and conventions, this approach to programming can be called OO, but just as assembler can be written procedurally, many procedural languages can be used to implement the various OO ideas above. I used to write C code that had structures containing function pointers and some gnarly macros to make them easier to call. BOOPSI provided a whole framework for runtime class extension and redefinition. However, the language does not provide any direct syntactical support to make this particularly easy or efficient to do compared to say C++. Consequently, C is considered a Procedural programming language where as C++ is considered an Object Oriented one. To get technical, C++ is multiparadigm as it provides support for OO (and other paradigms too such as metaprogramming) but doens't force them on you.

_________________
Doing stupid things for fun...

@matthey

Quote:

matthey wrote: BOOPSI is a general purpose OOP system (the superclass is a general purpose object). It is not limited to GUI elements even though most of the provided classes are used for them and communication between them. Datatypes is built on top of BOOPSI. The OOP modularity fits with the Amiga with existing modular data like GUI elements, images, structures, libraries, etc. encapsulated into objects. No object oriented language is required and I would rather have it this way as it allows us to use C which is more efficient than OOP languages (BOOPSI classes are Amiga shared libraries where C++ statically links object support code). Yes, the Amiga was built on modularity without OOP which is usually more efficient and fine when simple. Does the AmigaOS 4 IExec->function OOP change really help anything or is it just an inefficient hassle? BOOPSI allows to wrap objects around anything if OOP is wanted but it has not been used everywhere just to say it is OOP. The AmigaOS has better modularity and code sharing features than most other OSs with or without OOP.

Quote:

matthey wrote: Yea, to minimalist and more efficient OOP implementations instead of bloated ones. BOOPSI is minimalist but extendable. Look in the boot partition gadgets, images and datatypes directories to see how much it has been extended, especially if you have newer versions of AmigaOS. Look in the MUI directory to see more BOOPSI extensions. The base classes have been updated to be much nicer on newer AmigaOS versions as well. Kronos Quote: - BOOPSI requires tons of boilerplate code to make C do what C++ could do in 3 lines Three lines and 30kiB of code for the C++ static link library that is not shareable. All those gadgets, images, datatypes and MUI objects mentioned above are normal shared Amiga libraries. Kronos Quote: - BOOPSI leads to many potential bugs that are hard to diagnose OOP indirection makes programs more difficult to debug. It also degrades performance with indirect branches which CPUs can't predict well. CPUs with indirect branch predict often only predict the last branch destination among a whole list of destinations. BOOPSI tries to minimalise the number of indirect branches (some OOP purists would complain) and it has amazing code sharing which improves performance, reduces the computer footprint and exemplifies OOP principles. Kronos Quote: - modern OSes and languages did evolve quite a bit in the past 30 years so most of your criticism does not apply anymore. Just look at what a modern API and language can do in SwiftUI (and plenty others I never tried). Also OS4 uses a C++ OOP syntax to do something that is not OOP at all (noone sane has ever claimed otherwise). Modern programming languages, especially OOP languages, often cause major code bloat. If they work to speed up your programming then great but there is usually a code bloat and performance cost. C is still one of the most efficient languages although it does not provide everything ready made in a link library of bloat (but AmigaOS provides BOOPSI shared libraries). Traditional AmigaOS programming is not outdated technology but old school goodness that needs a little work here and there. IMO, the major improvement of languages is more about multi-threading features and enhancements where the Amiga doesn't support SMP.

Sorry Matt, but you're completely wrong here and the others were right.

BOOPSI is a complete crap as an OOP implementation which is also inefficient AND bloat. So, the exact opposite that you're claiming.

Actually this has nothing to do with the C++ linked et similar.

If you define a base class with some properties (instance attributes. And also class attributes) and methods, you've to provide all code whatever OOP implementation that you implement (so, BOOPSI included) IF you want to make it available to the external world. Which means that your class could be simply used. Or maybe extended.

Now think about a basic OOP example and translate it to real code with BOOPSI. Let's say that you've x (instance, to simply the example) and y methods. Could you tell me how much space is needed for an instance of such class? And how much code is generated for the methods?

For a classic VMT AKA vTable implementation the math is pretty simple.
The space needed for each instance is given by the size of the related struct plus the size of the pointer to the VMT (4 bytes for 32-bit systems and 8 bytes for 64-bit).
The space needed for the VMT is given by y * sizeof(POINTER).
The space needed for the code's methods is given only by the effective code which is needed to model the specific activity / behavior of the methods.

Now let's see what's needed at runtime when using an instance.
Accessing an instance attribute just requires... to access the specific member of the struct. Practically INSTANT.
Calling a (virtual) method requires to load the VMT pointer from the proper (hidden) field on the instance's struct. Then loading the pointer to the method from the specific entry on the VMT. Finally calling it. The last two steps could be just one on architectures like x86/x64 where you do a call referencing to memory, or the 68020+ with the double-indirect memory addressing mode.

Now think about how you could do it with the BOOPSI.

Putting aside the VMT, for the space you need AT least the size of the struct PLUS all space which is needed when you have to "build" the specific instance by passing all TAGs. With the added "bonus" that if a property requires less space of a LONG, you're wasting space. And if it's bigger than a LONG you've to ALLOCATE additional memory and pass a pointer to it into the TAG (AND you've to deallocate it when you've done with the instance).
Regarding the space needed for the code's methods you need the same for the VMT implementation PLUS all the code chain which is required to check the specific method tag which was called.
And here you ALSO need the space for the code which is required for setting / defining a (new) property for the instance.

Now let's see what's needed at runtime when using an instance.
Accessing an instance attribute requires to... call BOOPSI with the specific property's tag id. Then the dispatcher has to check this tag id and when (and IF) found do the proper thing (read it and give back to the call. Or set it).
Calling a method requires the boilerplate which is required for accessing a property.
So, again much more space (for all this additional boilerplate code) and much less performance.

On top of that you've to add the on a classic OOP implementation you cannot make mistakes like accessing the wrong property or calling the wrong method, because you cannot mess with the tags. AND the compiler is also taking care of the types used.

As you can see, BOOPSI is really the worst OOP implementation. EVER. And it's really indefensible!

Take a look a the Turbo Pascal 5.5 implementation https://edn.embarcadero.com/article/images/20803/TP_55_OOP_Guide.pdf and you can see how simple, easy, and efficient it is.

BTW, the example that you've shown is HORRIBLE and very difficult to read and understand.

@matthey

karlos did a better job explaining much of the history than I care to; I just want to affirm your point that "object oriented design", "object oriented programming" and "object oriented languages" are not all the same. I believe karlos is also affirming that. As he said (and I thought I did, but maybe not), the boundaries are not really clear-cut, though extreme OO enthusiasts would say otherwise.

OO programing & design is basically a kind of modular design. Just remember where the central focus of the design lies.

@cdimauro
Quote:

As you can see, BOOPSI is really the worst OOP implementation. EVER. And it's really indefensible!

Maybe not. Here's a valid example of Wirth-style Oberon:
Quote:

TYPE Figure = POINTER TO FigureRecord; TYPE FigureRecord = RECORD draw(self: Figure; canvas: Canvas); (* assume Canvas is defined *) END; TYPE Circle = POINTER TO CircleRecord; TYPE CircleRecord = RECORD(FigureRecord) x, y, radius: REAL; END; PROCEDURE draw(f: Figure; c: Canvas) BEGIN (* imagine something decent here *) END; PROCEDURE drawPerversely(f: Figure; c: Canvas) BEGIN (* imagine something indecent here *) END; VAR c1, c2: Circle; f1, f2: Figure; BEGIN (* main *) (* setup a canvas *) NEW(c1); NEW(c2); c1.draw = draw; c2.draw = drawPerversely; f1 = c1; f2 = c2; END;

If you don't understand what's happening, here's a summary: even though c1 and c2 are both circles, and you can draw them with static typing via c1.draw(c1, canvas); or with dynamic typing via f1.draw(f1, canvas);, the outcome of drawing each will be different. This, because the programmer initialized the variables' type-bound procedures to different values. This, because Oberon provides no facility for automatically initializing an object, so the programmer has to do this oneself (even if via setting up an Init function. Short of examining every last line of the source code, you basically have no guarantee of any consistency in the code. It should be obvious that this opens the door to all manner of mischief, never mind mistakes.

One can achieve this apex of confusion in other OO languages, but it is not standard practice, whereas it is one of the two major ways Oberon achieves achieve object-oriented programming.

Sorry for the long setup, but: It's been a long time since I BOOPSI'd, so: is this perversion possible there, too? I didn't think that was the case, but maybe I misremember. If not, I'd say BOOPSI is not quite as bad as Oberon.

Kronos Quote:

https://en.wikipedia.org/wiki/IOS The rest of your post(s) is of similar "quality" so I won't bother.

iOS != macOS

The kernel (Mach) of both is derived from Darwin (BSD OS) and different but converging.

https://en.wikipedia.org/wiki/IOS#XNU_kernel Quote:

In the beginning, iOS had a kernel version usually higher than the corresponding version of macOS. Over time, the kernels of iOS and macOS have gotten closer. This is not surprising, considering that iOS introduced new features (such as the ASLR Kernel, the default freezer, and various security-strengthening features) that were first incorporated and subsequently arrived on macOS. It appears Apple is gradually merging the iOS and macOS kernels over time. The build date for each version varies slightly between processors. This is due to the fact that the builds are sequential. The latest version of the Darwin Kernel updated to iOS 13.6 is 19.6.0, dated July 27, 2020, while for iOS 14 beta 4 it is 20.0.0, dated July 27, 2020.

The OS is much more than the kernel. Has Darwin based macOS ever limited multitasking?

https://en.wikipedia.org/wiki/IOS#Multitasking Quote:

Multitasking for iOS was first released in June 2010 along with the release of iOS 4. Only certain devices—iPhone 4, iPhone 3GS, and iPod Touch 3rd generation—were able to multitask. The iPad did not get multitasking until iOS 4.2.1 in that November. The implementation of multitasking in iOS has been criticized for its approach, which limits the work that applications in the background can perform to a limited function set and requires application developers to add explicit support for it.

As secure as BSD is, iOS is a little sandboxed (virtual hardware) app environment from the users perspective and far from macOS general purpose capabilities and control. This is a trend as security becomes more important. The OS has control of the owner's hardware instead of the owner. I wouldn't be surprised if macOS is heading more in this direction for convergence with iOS. Security and maintenance are easier on hardware which limits the power of the owner/user. The macOS could throw away much of the general purpose OS that isn't needed and converge into an app execution environment like iOS.

Dear Matthew Hey my friend,


sorry to bother you again with my question.

Please help us understand where your "immense" CPU knowledge comes from?
Are you a fully self educated ten Dan black belt Wikipedia expert?

Or did you study CPU design?
Have you some decades of work experience as ASIC developer?
Did you work for some major company like IBM or INTEL in this area?
Can you please tell us what your _real_ profession is?


I know you sometimes brag about your time in the Apollo-team: "and then I told them how to optimize this and that"

Or was rather that the Apollo-Team did very quickly kick you?
As it became apparent that you are only pretender and not know anything about the stuff you talked about?

Thank you in advance for shedding some light

Dear Cesare Di Mauro,

Quote:

BOOPSI is a complete crap as an OOP implementation which is also inefficient AND bloat. So, the exact opposite that you're claiming.

This a clear and strong judgment from you.

Help us understand on what experience you based this.
How many Amiga programs using BOOBSI, did you write?
Even how many Amiga programs in total did you write?