Thread overview | |||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
April 28, 2008 This needs a different approach | ||||
---|---|---|---|---|
| ||||
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 :) |
April 28, 2008 Re: This needs a different approach | ||||
---|---|---|---|---|
| ||||
Posted in reply to Saaa | "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 |
April 28, 2008 Re: This needs a different approach | ||||
---|---|---|---|---|
| ||||
Posted in reply to Saaa | 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?
|
April 28, 2008 Re: This needs a different approach | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert Fraser | "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. |
April 28, 2008 Re: This needs a different approach | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | >> >> 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: Erm, how does one do this? > > groupModule.get(data.type).eat(); > > -Steve > > |
April 28, 2008 Re: This needs a different approach | ||||
---|---|---|---|---|
| ||||
Posted in reply to Saaa | "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 :) >>> >> >> 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 |
April 28, 2008 Re: This needs a different approach | ||||
---|---|---|---|---|
| ||||
Posted in reply to Saaa | On Mon, 28 Apr 2008 19:22:15 +0200, Saaa wrote:
> "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.
|
April 28, 2008 Re: This needs a different approach | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jesse Phillips |
> 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.
Thanks, I'll look into it.
|
April 28, 2008 Re: This needs a different approach | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | > 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; } } |
April 28, 2008 Re: This needs a different approach | ||||
---|---|---|---|---|
| ||||
Posted in reply to Saaa | "Saaa" wrote
>> 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
|
Copyright © 1999-2021 by the D Language Foundation