
Object-oriented design patterns in the Linux kernel (2011) - zwliew
https://lwn.net/Articles/444910/
======
ghosthamlet
This is part 2 for data inheritance:
[https://lwn.net/Articles/446317/](https://lwn.net/Articles/446317/)

------
black-tea
This is a great article. So many programmers (including me) start with a
language that does OO stuff for them. But it's really important to understand
that it's not really magic and that a lower level language gives you more
flexibility in which methods to use.

The difference between C and Lisp is that the latter allows you to extend the
language in a way that essentially documents your technique in the same way
C++ extends C to document its chosen techniques. If you saw the code in the
article without having read this article and without suitable comments in the
code, it would be really unclear what the programmer is actually doing.

~~~
tyingq
Perl's OO is interesting in this regard. They use a function called bless() to
mark something as an object of a specific class. No magic keywords, methods
are just functions in a specific namespace/package, etc.

So, while it has it's warts, OO in Perl is very easy to follow.

~~~
knome
Didn't most perl5 OOP move to the Moose library, that set a bunch of standard
method names and hid all the bless'ing stuff in its internals?

~~~
lizmat
I recently wrote an article about objects / classes in Perl 5 and Perl 6,
which also touches on Moose: [https://opensource.com/article/18/11/how-make-
perl-more-clas...](https://opensource.com/article/18/11/how-make-perl-more-
classy)

~~~
tyingq
Your article does a pretty good job of showing what I meant. The Perl 5
example is more verbose, but easy to follow how OO is implemented. Perl 6
hides it. Not arguing Perl 5's approach as better. Just that it makes OO easy
to understand for a procedural developer.

~~~
lizmat
Thank you. FWIW, I like to work with things that do what I want, without
having to precisely understand how they do it.

