This needs a different approach

[Saaa]

>> Wouldn't a function table be more appropriate?
>
> Maybe :)  You keep changing the rules, so I'm not sure now.
Yeah, sorry about that. (Stricly speaking it more like elaboriting than 
changin ;)

>
> From your original code it appears you are calling functions from modules, 
> I don't see how those functions are going to change during execution of 
> the code.
I didn't mean to say this, I meant to say that fruits may change into other 
fruits.
(although not as often as I mentioned)

>I'm really confused by your example, but in general, using OO principals, 
>you are essentially hiding the specific implementation behind a generic 
>interface.  The generic interface is something that is Edible.  The 
>specifics of what happens when you call it on an instance of Edible should 
>be irrelavent to the calling code.  It just knows that something needs to 
>be eaten, it doesn't care how that is done :)  Imagine later on down the 
>road you need to add another fruit.  This is trivial, just add it to the 
>initialized array, and every instance that calls get() doesn't care that 
>get() can now return another fruit type.  If you had your switch statement, 
>then you have to update it in the calling code.  You could even dynamically 
>map values to fruits.  All this, and the caller of get() doesn't have to 
>care what fruits there are, and how they are used.  It just knows that 
>whatever is returned from get() has an eat() function which it needs to 
>call.
>
> Separating interface from implementation is not only useful, but is more 
> understandable, maintainable, and generally contains less bugs.  That's 
> not to say you have to use OO principals to solve every problem, but a 
> problem in which you are calling a similar function on lots of similar 
> objects (or modules) screams to be solved with OO :)  You should find a 
> good book on design patterns, they are immensely useful and mostly 
> universal (though usually geared towards Java).  I'm sure there is one 
> that solves this.
>
> -Steve

Using the switch with a function table wouldn't be more error-prone as how 
difficult can it be to find that I left out a fruit from the function table 
or switch. As for the restriction of the interface on all the fruits; 
couldn't this be done on modules? forcing every module to implement an eat 
function? (just asking :)

I can understand the need of abstraction if it weren't a one-man show. But 
to me it seems like more work, most of the time. I really appreciate your 
code as it helps me understand oop, but to me it is not more understandable 
than the function table: also understanding function tables to memory usage 
is straight forward. Maybe it is my lack of understanding oop but most of 
the time I can't translate it to memory usage that easily (which is the 
point of oop, I think?).

With the arsenal of D functionality, wouldn't it be possible to let the 
compiler generate the function table code?