Re: [dev] Conversation with Anselm R. Garbe of suckless.org

On Mon, Sep 14, 2009 at 6:16 PM, Amit Uttamchandani <atu13439_AT_csun.edu> wrote:
> On Mon, Sep 14, 2009 at 08:59:12AM +0100, Anselm R Garbe wrote:
>> > Just curious as to the arguments against OO programming. All the classes
>> > I have taken in uni always trumpet OO. I have been using it ever since
>> > but I do agree that it can get out of hand at times.
>>
>> Let me paste some response I gave recently via priv mail:
>>
>
> Thanks for sharing the response, it helped in understanding your
> viewpoint.
>
>>
>> > My question is that, there are some approaches that 'seem'
>> > easier/logical to implement with OO, how does one approach this in a not
>> > OO way?
>>
>> Well that was my excuse when I was a fan of OO as well, that there are
>> plenty problems "better solved" using OO. When carefully thinking
>> about it, I always concluded, no, this problem is better not solved
>> the OO way.
>>
>> Can you give examples where you think OO is the better choice?
>>
>
> Some examples:
>
>  1. I designed a software to automate testing of the boxes that we
>  build. The main language used is Python (I guess it's hard to avoid OO
>  when using python). Basically the design is such that I have a test
>  case class that is used when instantiating different test cases
>  (attributes include: name, status, tester, etc.). How would you
>  approach this in a non-OO way?

It is perfectly possible to write Python code without doing OO, as
long as you stay away from the awful 'frameworks' out there that force
you all kinds of insane crap like mixins down your throat.

For example I just wrote a tracker for App Engine in python without
even using a single class: http://repo.cat-v.org/atrack/ Other people
had writen trackers before, but they used OO and they were *much*
bigger, much more complicated, much slower, and much harder to hack
on.

Note that using classes in python is OK, as long as you just use them
as structs, and *never* *ever* *under any circumstance* use
inheritance. And there is the main problem because some APIs pretty
much force you to use inheritance, but usually that can be isolated
with some care, but it is a big pain.

(Also 'objects' in python act much as dictionaries if you ignore the
inheritance stuff, so dictionaries and classes can be used somewhat
interchangeably).

>
>  2. A colleague of mine needed to design a packet generation engines for
>  our box. He used OO concepts in CC by using techniques such as VTABLE,
>  defines for methods, classes, etc:
>
>  /**
>  * Macros for declaring classes
>  */
>  #define CLASS(CX, SX)\
>     typedef struct CX *CX;\
>     struct CX {struct SX super;
>  #define IMPLEMENTS(IX) struct IX *IX
>  #define VTABLE(CX, SX) };\
>     extern struct CX##Class __##CX;\
>     typedef struct CX##Class *CX##Class;\
>     struct CX##Class {struct SX##Class super;
>   #define METHODS };
>   #define END_CLASS
>
>  So then, he can instantiate multiple different engines depending on
>  processor load, etc.

Your friend should beaten up semi-unconscious with metal bars, thrown
into a big hole in the ground, and then have the hole filed with
liquid feces until he drowns.

Peace

uriel

>
>> Kind regards,
>> Anselm
>>
>
> Thanks again, this discussion is really helping me.
>
>
>
Received on Tue Sep 15 2009 - 00:35:46 UTC