I have this piece of code:
enum { APPLE, PEAR .. PLUM}
switch (data.type)
{
case APPLE:
groupModule.appleModule.eat();
break;
case PEAR:
groupModule.pearModule.eat();
break;
..
..
case PLUM:
groupModule.plumModule.eat();
break;
default:
break;
}
As the function is always the same I'd rather see a lookup iso an iteration
over all options.. but how?
groupModule.(data.type).eat();
Something like this is both faster and a lot less to code :)
"Saaa" <empty needmail.com> wrote in message
news:fv4q7a$1nde$1 digitalmars.com...
I have this piece of code:
enum { APPLE, PEAR .. PLUM}
switch (data.type)
{
case APPLE:
groupModule.appleModule.eat();
break;
case PEAR:
groupModule.pearModule.eat();
break;
..
..
case PLUM:
groupModule.plumModule.eat();
break;
default:
break;
}
As the function is always the same I'd rather see a lookup iso an
iteration over all options.. but how?
groupModule.(data.type).eat();
Something like this is both faster and a lot less to code :)
Not sure if this works, but what you probably want is a function table:
auto functionArray = [APPLE:&groupModule.appleModule.eat,
PEAR:&groupModule.pearModule.eat, .., PLUM:&groupModule.plumModule.eat];
functionArray[data.type]();
Another option is to store your modules in the groupModule in an array and
just get a common interface returned via a function get:
groupModule.get(data.type).eat();
-Steve
I have this piece of code:
enum { APPLE, PEAR .. PLUM}
switch (data.type)
{
case APPLE:
groupModule.appleModule.eat();
break;
case PEAR:
groupModule.pearModule.eat();
break;
..
..
case PLUM:
groupModule.plumModule.eat();
break;
default:
break;
}
As the function is always the same I'd rather see a lookup iso an
iteration over all options.. but how?
groupModule.(data.type).eat();
Something like this is both faster and a lot less to code :)
Not sure if this works, but what you probably want is a function table:
auto functionArray = [APPLE:&groupModule.appleModule.eat,
PEAR:&groupModule.pearModule.eat, .., PLUM:&groupModule.plumModule.eat];
functionArray[data.type]();
Ok, that works; I think :) although the array would become very large.
Another option is to store your modules in the groupModule in an array and
just get a common interface returned via a function get:
I have this piece of code:
enum { APPLE, PEAR .. PLUM}
switch (data.type)
{
case APPLE:
groupModule.appleModule.eat();
break;
case PEAR:
groupModule.pearModule.eat();
break;
..
..
case PLUM:
groupModule.plumModule.eat();
break;
default:
break;
}
As the function is always the same I'd rather see a lookup iso an
iteration over all options.. but how?
groupModule.(data.type).eat();
Something like this is both faster and a lot less to code :)
Not sure if this works, but what you probably want is a function table:
auto functionArray = [APPLE:&groupModule.appleModule.eat,
PEAR:&groupModule.pearModule.eat, .., PLUM:&groupModule.plumModule.eat];
functionArray[data.type]();
Ok, that works; I think :) although the array would become very large.
Not any larger than the code that is generated from your switch statement :)
In fact, compilers sometimes optimize code like yours into a function array.
Another option is to store your modules in the groupModule in an array
and just get a common interface returned via a function get:
Erm, how does one do this?
I was assuming your groupModule was a class, but now I think it might be a
module (duh!).
You should seriously consider putting these things into classes instead of
modules, and looking up the right interface based on the data type from a
function. For example:
interface Edible
{
void eat();
}
class Pear : Edible
{
void eat() {...}
}
static Edible[] fruits;
static this()
{
fruits = [APPLE:new Apple(), PEAR:new Pear()...].dup;
}
Edible get(uint type)
{
if(type > fruits.length)
return null;
return fruits[type];
}
Robert is right, this is precisely the thing that OO programming was created
for :)
-Steve
I was assuming your groupModule was a class, but now I think it might be a
module (duh!).
; )
You should seriously consider putting these things into classes instead of
modules, and looking up the right interface based on the data type from a
function. For example:
interface Edible
{
void eat();
}
class Pear : Edible
{
void eat() {...}
}
static Edible[] fruits;
static this()
{
fruits = [APPLE:new Apple(), PEAR:new Pear()...].dup;
}
Edible get(uint type)
{
if(type > fruits.length)
return null;
return fruits[type];
}
Robert is right, this is precisely the thing that OO programming was
created for :)
-Steve
I should have written this before, but data is actually an array.
enum { APPLE, PEAR .. PLUM}
for(i=0;i<1000;i++)
{
switch (data[i].type)
{
case APPLE:
groupModule.appleModule.eat();
break;
case PEAR:
groupModule.pearModule.eat();
break;
..
..
case PLUM:
groupModule.plumModule.eat();
break;
default:
break;
}
}
You should seriously consider putting these things into classes instead
of modules, and looking up the right interface based on the data type
from a function. For example:
interface Edible
{
void eat();
}
class Pear : Edible
{
void eat() {...}
}
static Edible[] fruits;
static this()
{
fruits = [APPLE:new Apple(), PEAR:new Pear()...].dup;
}
Edible get(uint type)
{
if(type > fruits.length)
return null;
return fruits[type];
}
Robert is right, this is precisely the thing that OO programming was
created for :)
-Steve
I should have written this before, but data is actually an array.
enum { APPLE, PEAR .. PLUM}
for(i=0;i<1000;i++)
{
switch (data[i].type)
{
case APPLE:
groupModule.appleModule.eat();
break;
case PEAR:
groupModule.pearModule.eat();
break;
..
..
case PLUM:
groupModule.plumModule.eat();
break;
default:
break;
}
}
So with the get method I outlined above, the switch code becomes:
get(data[i].type).eat();
-Steve
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?
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?
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.
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
Maybe :) You keep changing the rules, so I'm not sure now.
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.
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?
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?
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.
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).
ok that sounds better ... until now
As to how the flow is; that loop is called 30 times / sec. And eating a
fruit may change it to another fruit.
and why does eating a fruit change it to another?
is that the way your current algorithm work - or why does fruits change
if eaten? more story details, please...
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).
ok that sounds better ... until now
As to how the flow is; that loop is called 30 times / sec. And eating a
fruit may change it to another fruit.
and why does eating a fruit change it to another?
is that the way your current algorithm work - or why does fruits change if
eaten? more story details, please...
In oop style this might sound a bit strange, but in my setup it is the same
as changing the type number.
A different type means a different way of being eaten.
Apr 29 2008
↑ ↓ ← → dennis luehring <dl.soluz gmx.net> writes:
and why does eating a fruit change it to another?
is that the way your current algorithm work - or why does fruits change if
eaten? more story details, please...
Does this really matter?
In oop style this might sound a bit strange, but in my setup it is the same
as changing the type number.
is an procedural codesnippet of how it should work :-)
A different type means a different way of being eaten.
sometimes people want it all in just one array maybe you need another one
Apr 29 2008
↑ ↓ ←→ Robert Fraser <fraserofthenight gmail.com> writes:
Saaa wrote:
I have this piece of code:
enum { APPLE, PEAR .. PLUM}
switch (data.type)
{
case APPLE:
groupModule.appleModule.eat();
break;
case PEAR:
groupModule.pearModule.eat();
break;
..
..
case PLUM:
groupModule.plumModule.eat();
break;
default:
break;
}
As the function is always the same I'd rather see a lookup iso an iteration
over all options.. but how?
groupModule.(data.type).eat();
Something like this is both faster and a lot less to code :)
Isn't this what inheritance and polymorphism is all about?
"Robert Fraser" <fraserofthenight gmail.com> wrote in message
news:fv4t21$1ue1$1 digitalmars.com...
Saaa wrote:
I have this piece of code:
enum { APPLE, PEAR .. PLUM}
switch (data.type)
{
case APPLE:
groupModule.appleModule.eat();
break;
case PEAR:
groupModule.pearModule.eat();
break;
..
..
case PLUM:
groupModule.plumModule.eat();
break;
default:
break;
}
As the function is always the same I'd rather see a lookup iso an
iteration over all options.. but how?
groupModule.(data.type).eat();
Something like this is both faster and a lot less to code :)
Isn't this what inheritance and polymorphism is all about?
Could you elaborate on that?
The eat functions are totally different btw.
Apr 28 2008
↑ ↓ ←→ Robert Fraser <fraserofthenight gmail.com> writes:
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" <empty needmail.com> wrote in message
news:fv7ht6$2d6c$1 digitalmars.com...
How would you make the array of fruits?
Something I can iterate over. like:
fruits[ APPLE,PLUM,APPLE ... PEAR,PLUM];
IFruit[] fruits = [APPLE, PLUM, APPLE ... PEAR, PLUM];
Since all fruits inherit from IFruit, they can all be represented as IFruit
references. So, if you have an array of IFruit, you can put all different
kinds of fruits in it.
IFruit[] fruits = [APPLE, PLUM, APPLE ... PEAR, PLUM];
Since all fruits inherit from IFruit, they can all be represented as
IFruit references. So, if you have an array of IFruit, you can put all
different kinds of fruits in it.
Calling 'fruit[2].eat();' would call eat() from that specific APPLE, right?
IFruit[] fruits = [APPLE, PLUM, APPLE ... PEAR, PLUM];
Since all fruits inherit from IFruit, they can all be represented as
IFruit references. So, if you have an array of IFruit, you can put all
different kinds of fruits in it.
Calling 'fruit[2].eat();' would call eat() from that specific APPLE,
right?
Changing fruit[2] to PLUM would go how?
I would like the PLUM to retain data from that specific APPLE.
That data is of the same type over all fruits.
IFruit[] fruits = [APPLE, PLUM, APPLE ... PEAR, PLUM];
Since all fruits inherit from IFruit, they can all be represented as
IFruit references. So, if you have an array of IFruit, you can put all
different kinds of fruits in it.
Calling 'fruit[2].eat();' would call eat() from that specific APPLE,
right?
IFruit[] fruits = [APPLE, PLUM, APPLE ... PEAR, PLUM];
Since all fruits inherit from IFruit, they can all be represented as
IFruit references. So, if you have an array of IFruit, you can put all
different kinds of fruits in it.
Calling 'fruit[2].eat();' would call eat() from that specific APPLE,
right?
"Robert Fraser" <fraserofthenight gmail.com> wrote in message
news:fv4t21$1ue1$1 digitalmars.com...
Saaa wrote:
I have this piece of code:
enum { APPLE, PEAR .. PLUM}
switch (data.type)
{
case APPLE:
groupModule.appleModule.eat();
break;
case PEAR:
groupModule.pearModule.eat();
break;
..
..
case PLUM:
groupModule.plumModule.eat();
break;
default:
break;
}
As the function is always the same I'd rather see a lookup iso an
iteration over all options.. but how?
groupModule.(data.type).eat();
Something like this is both faster and a lot less to code :)
Isn't this what inheritance and polymorphism is all about?
Could you elaborate on that?
The eat functions are totally different btw.
Say you have a Fruit interface with the function eat();
You could then have an Apple, Plum, Pear class that implements Fruit. If
you have data as one of these types maybe in a variable of type Fruit you
could then just call data.eat(). Though you don't seem to have it set up
in this way, and my not be the needed approach for what you are trying to
do. I'm tired so I'm not going in as much depth as I should.
Say you have a Fruit interface with the function eat();
You could then have an Apple, Plum, Pear class that implements Fruit. If
you have data as one of these types maybe in a variable of type Fruit you
could then just call data.eat(). Though you don't seem to have it set up
in this way, and my not be the needed approach for what you are trying to
do. I'm tired so I'm not going in as much depth as I should.
Home
| Search
| C & C++
| D
| DMDScript
| News Groups
| index
| prev
| next