Quoting George Greer <greerga@CIRCLEMUD.ORG>:
> On Tue, 11 Dec 2001, krenshala wrote:
>
> >Has anyone (aside from me :) considered coding
> an IS_CLASS(ch,<CLASS>)
> >function that can replace the IS_<CLASS>(ch)
> functions?
>
> Why not use GET_CLASS(ch) == CLASS_xxx ? I'm not
> sure what IS_CLERIC buys
> other than !IS_NPC() checks (which are bogus
> anyway if you give mobiles
> classes), but it's there.
I'm not able to comment too extensively, as I'm sitting
in a ridiculously expensive--and unnecessary--training
session which is returning from lunch at any second.
If someone has beaten me to this point (I haven't got
all the way through my inbox yet), my apologies.
The other advantage that IS_CLERIC, IS_MAGIC_USER, and
so on is that you can use them more expansively.
Perhaps it was not intended this way, but the concept
of a variety of the same class is more easily
implemented into the current setup:
#define IS_MAGIC_USER(ch) (!IS_NPC(ch) &&
(GET_CLASS(ch) == CLASS_FIRE_MAGE ||
(GET_CLASS(ch) == CLASS_COLD_MAGE))
Just a simple example. I used that at one point in a
draft of multi- and sub-classing that I wrote up. We
can already check if someone's class is something.
Of course, you could also write the macro in two
seconds. But it makes lazy people (like myself,
sometimes) able to make it "work" without going after
every grepped line of code.
Overall, I suppose there aren't any huge benefits, or
any huge drawbacks. And the sets can coexist happily,
as well.
Summary: leave it alone. :)
-k.
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
| Newbie List: http://groups.yahoo.com/group/circle-newbies/ |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 06/24/03 PDT