I think I get your code now :)

Tell me if I'm wrong:
This approach makes initializing the  fruits list a bit more complex.
Changing an item in the list to another fruit requires the GC (the previous
instance needs to be deleted)
Changing an item is more costly than changing a number. (A lot of the items
get changed 30 times per second)

Wouldn't a function table be more appropriate?

>
> So with the get method I outlined above, the switch code becomes:
>
> get(data[i].type).eat();
>
> -Steve
> 

Premature optimization is bad.

Try doing it that way, and only optimize it if you see it's working slowly.

Saaa escribió:
> I think I get your code now :)
> 
> Tell me if I'm wrong:
> This approach makes initializing the  fruits list a bit more complex.
> Changing an item in the list to another fruit requires the GC (the previous instance needs to be deleted)
> Changing an item is more costly than changing a number. (A lot of the items get changed 30 times per second)
> 
> Wouldn't a function table be more appropriate?
> 
>> So with the get method I outlined above, the switch code becomes:
>>
>> get(data[i].type).eat();
>>
>> -Steve
>>
> 
> 

> Premature optimization is bad.
>
> Try doing it that way, and only optimize it if you see it's working slowly.
>

What is bad about function tables?
Implementing function tables should be easy, I think :)
At least a lot less work than rewriting everything into classes.

I'm not optimizing, I'm simply deciding which approach is best.

Why would using function tables be an optimization?

Saaa escribió:
>> Premature optimization is bad.
>>
>> Try doing it that way, and only optimize it if you see it's working slowly.
>>
> 
> What is bad about function tables?
> Implementing function tables should be easy, I think :)
> At least a lot less work than rewriting everything into classes.
> 
> I'm not optimizing, I'm simply deciding which approach is best.
> 
> Why would using function tables be an optimization? 

I just mentioned optimization because you said "Changing an item is more costly than changing a number. (A lot of the items get changed 30 times per second)".

I'm more into solving this using classes and inheritance. If the compiler can do the function table for you, why bother?

Saaa wrote:
> Could you elaborate on that?
> The eat functions are totally different btw. 

Here's how I would solve it:

interface IFruit
{
    void eat();
}

IFruit APPLE;
IFruit PEAR;
//...
IFruit PLUM;

static this()
{
    APPLE = new class() IFruit
    {
        void eat()
        {
            tasteTheJuicyGoodness();
        }
    }

    // ...
}

You could initialize them in different modules, if you wanted, too.

"Saaa" wrote
>I think I get your code now :)
>
> Tell me if I'm wrong:
> This approach makes initializing the  fruits list a bit more complex.
> Changing an item in the list to another fruit requires the GC (the
> previous instance needs to be deleted)
> Changing an item is more costly than changing a number. (A lot of the
> items get changed 30 times per second)
>
> Wouldn't a function table be more appropriate?

Maybe :)  You keep changing the rules, so I'm not sure now.

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'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

Saaa schrieb:

> Tell me if I'm wrong:
> This approach makes initializing the  fruits list a bit more complex.
> Changing an item in the list to another fruit requires the GC (the previous instance needs to be deleted)
> Changing an item is more costly than changing a number. (A lot of the items get changed 30 times per second)

describe the program flow - but without code

does the fruit realy change? - why?

>
> I'm more into solving this using classes and inheritance. If the compiler can do the function table for you, why bother?

I can understand your position ;)
But I didn't use any classes.

If the compiler would optimize the switch to a function table anyways I would just keep it like it is now although learning to use classes in D sounds intriguing as well.

>> Tell me if I'm wrong:
>> This approach makes initializing the  fruits list a bit more complex.
>> Changing an item in the list to another fruit requires the GC (the
>> previous instance needs to be deleted)
>> Changing an item is more costly than changing a number. (A lot of the
>> items get changed 30 times per second)
>
> describe the program flow - but without code
>
> does the fruit realy change? - why?

I confused two arrays yesterday. The fruits don't change as often as I said
(more like once every few seconds for only a small percentage of all
fruits).
As to how the flow is; that loop is called 30 times / sec. And eating a
fruit may change it to another fruit.

>> 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?