Object Oriented Programming in the Kernel

[Kfeavel]

Moving the conversation out of #171 and into an actual post.

---

@JamesOrson:
I have a question about all the functions in this file as a whole. Is there a reason we have defined these all as separate functions instead of as static functions and member functions of px_task_t?

All of these functions take at least one task parameter and have px_tasks prefixed to them, sort of cluttering up the code a bit imo and making it easier to have my eyes glaze over while reading the code.

---

@micahswitzer:
This has been a C-only project pretty much until now. I'm totally for using C++ objects and structs with member functions, but we also must be careful that we don't just end up re-writing the entire kernel (unless we want to do that). Maybe we can continue the discussion of incorporating more C++ code/features somewhere else?

---

@Kfeavel
I personally would prefer to avoid OOP unless it makes sense. As an example, it makes sense for drivers to be OOP since they all need to follow a certain format. However, I prefer procedural programming over OOP and have tried to keep to that throughout Panix. The main reason that C++ was chosen was simply to have the choice to do OOP when it is desired without having to mix the two languages.

---

@JamesOrson
I understand that we all have wounds from bad OOP. Same here.

But in all honesty, what's the difference in this case with moving the passed in task parameter to a this for the functions, while also removing the repetitive px_tasks_ prefix? In a sense, by moving them to member functions, you get free namespacing and shorter function names.

---

@JamesOrson
To lay my cards on the table though, I am very inclined to functional OOP. I hate state and I love types and classes. Hence my pushes for things like enums and functions defined within types.

---

@Kfeavel
My biggest problem with OOP is that I've been bitten by it hard before when doing kernel development. Problems with OOP and getting OOP to work properly is part of the reason Panix v2 died and I would like to avoid that as much as possible. OOP just brings extra assumptions and requirements into play that normally would not be a concern when doing procedural programming. I also find it easier to debug procedural code vs. OOP code since inheritance and other factors do not have to be taken into account.

---