rlt3

The problem is that most programmers today aren't apart of either of those groups but apart of a third, totally separate group: programmers who pick and prod and then glue lines of code together.

>Is the need to bench then add an actor the only way you "allow" transfer of children between parent actors?

Currently, yes. Since this is sort of an entity component system and that actors can always create more children anytime they want, I suppose I just always assumed that actors could be "spun-up" with any sort of functionality and then deleted when not used.

Benching/Joining an actor is more for handling errors at runtime or for debugging ("If I temporarily remove this actor will it solve my issue?").

>I'm guessing the author is using "traditional" in the sense of what is traditionally taught

This is correct and it's my mistake for not making this more clear.

>The approach to the missing "message" functionality would be either to create a class

Yeah, I explicitly covered this. I don't feel like piling some 'controller' object on top of other objects necessarily accomplishes what I'm after.

But it does work and I've used the pattern plenty.

I should have a tutorial out very soon. The documentation is not yet complete but does have a few examples.

Also, of course it's object-oriented. The article is titled a "healthy" hatred for a reason.

>I'm guessing your comments are based on seeing a lot of poor practices masquerading as OOP which affects what you think OOP actually is

I personally feel that the current OOP model eventually devolves into the bullet points you listed given enough complexity.

One reason why I think this occurs is that there is no concept of a 'message' in OOP, only methods or functions of a class. There's explicit coupling even when calling a method with no arguments because you know the method is valid for that object.

Contrast this with the example of the 'listener' in the room. A speaker broadcasts his message but the independent agents ultimately decide what to do with that message.

The OOP approach calls "object->listen" on each listener. My approach simply broadcasts the message and lets the objects determine how to handle it themselves.

His point was that sometimes business owners can get used to applying a template. It's a bookstore so it gets the bookstore template -- 4000 books and a coffee shop, right? Instead of applying this template, an owner with a pulse on the business can see what their customers are doing/buying/wanting and can change accordingly rather than apply a template.