ID:151739
 
Say I wanted a Multipurpose Proc that handles say 80% of my games commands and such, what would be the pros and cons of this sort of thing.

Example:
proc
Process(category, topic)
if(category=="Death")
if(topic=="Player")
//Player Dies Here
return
if(topic=="Enemy")
//Enemy Dies Here

if(category=="Attack")
if(topic=="Sword")
//Sword Attack Here
return
if(topic=="Gun")
//Gun Attack Here

And it would go on and on.. And obviously it would have more than just category and topic if it is going to be doing attacks and such.

Discuss?
Pros: None?
Cons: You can't pass anything extra into it (players, objs, etc. unless you want to use the args list), there's no point in doing it, you have to have the strings exact or something won't execute (like if you put "player" instead of "Player"), and then the fact that it's just a dumb design idea.
The only pros I could really see are easy tracking.
It would cause extra unnecessary processing on near every command, and would be incredibly long/hard to work with. Would things in it call other things in it?
In response to Falacy
Falacy wrote:
The only pros I could really see are easy tracking.
It would cause extra unnecessary processing on near every command, and would be incredibly long/hard to work with. Would things in it call other things in it?

Possibly. It would just have to call itself using different args.
In response to Slime Lord
Unless you use parameters. Maybe the args list variable for procs.

Either way, there are no real pros to the idea.
Also, I would hope switch() was used instead of if()s. :P
VolksBlade wrote:
Say I wanted a Multipurpose Proc that handles say 80% of my games commands and such, what would be the pros and cons of this sort of thing.

Example:
proc
> Process(category, topic)
> if(category=="Death")
> if(topic=="Player")
> //Player Dies Here
> return
> if(topic=="Enemy")
> //Enemy Dies Here
>
> if(category=="Attack")
> if(topic=="Sword")
> //Sword Attack Here
> return
> if(topic=="Gun")
> //Gun Attack Here

And it would go on and on.. And obviously it would have more than just category and topic if it is going to be doing attacks and such.

Discuss?

It looks as though you're trying to put together a basic event system. If so, a better and more efficient way to handle it would be to use datums to handle your processing. Instead of a global Process procedure, consider using an event datum, which can process it's own data.

The biggest con that I can see off hand is that the procedure will take time to evaluate events. If you have several events coming in rapidly, the procedure could bottleneck, resulting in a slowdown at best or a crash at worst. By treating each option as it's own event, you can simultaneously process a much larger event queue.
In response to CriticalBotch
I see, thank you.
Continue to discuss with yourselves, but I got what I needed. Thanks all.
This is pretty much the antithesis of modular programming, which should be a good priority for most developers. Just a really bad idea.
In response to Popisfizzy
Popisfizzy wrote:
This is pretty much the antithesis of modular programming, which should be a good priority for most developers. Just a really bad idea.

So if it is a good priority for most developers how is it a really bad idea? Is it the way it was coded or just bad period?
In response to VolksBlade
He referred to modular programming as the good priority, and then he said your code employs the opposite of that.
In response to Kaioken
Ah. Ok. Thanks.
In response to VolksBlade
After a good search, I have yet to find a good explanation of a Modular Program, anyone mind linking me to where I can learn about it?
In response to VolksBlade
VolksBlade wrote:
After a good search, I have yet to find a good explanation of a Modular Program, anyone mind linking me to where I can learn about it?

A good search eh? This search turned up plenty: http://www.google.com/search?q=modular+programming

However, a better concept to describe what we're talking about is Object Oriented Programming (OOP): http://en.wikipedia.org/wiki/Object-oriented_programming

Specifically "The methodology focuses on data rather than processes, with programs composed of self-sufficient modules (objects) each containing all the information needed to manipulate its own data structure."

Basically, discrete units of data handle their own functions.


The two concepts (discrete names) are different, but share some commonality. However, OOP is often termed "modular" programming due to it's conceptually modular nature.
In response to VolksBlade
You forgot to search Dream Makers!
In response to CriticalBotch
Alright thanks.
Actually, I can think of at least one beneficial scenario to doing it this way, and that is if you really want to be a security freak. If you're passing all your commands through one proc, you've a nice little gateway to throw in whatever security code you want to filter the validity of commands.

That said, is it necessary to do it this way? Probably not.
Of course that there are niche situations when such a thing may be beneficial - the point is to do something like this only when there it's required to do what you want, not to do it just to "have a multipurpose proc" and then look for potential benefits it may have.
In response to Kaioken
Yeah. After reading about the Modular Programming, I am now making everything that I can Modular, because it is saving me time and lots of code (and is a lot easier)
In response to Geldonyetich
If you take a look at aspect-oriented programming, it's kind of like that, and yes it is very useful for security.