On Wed, Jan 05, 2011 at 07:06:12PM +1000, Jude wrote:
> On Wed, Jan 5, 2011 at 7:04 PM, Jude Brown
> > commit 363d84146c1a0787a3ebf2c83b6dbc748569652c
> >    Dump the monster enum comments.
> >
> >    As with the previous commit, can be reverted if it is felt that the
> >    monster number comments are necessary. They are almost always hideously
> >    out of date, and as we refer to monster via "MONS_XXX" rather than "31",
> >    unnecessary.
> >

Hell yeah!
I tried to do this almost a year ago, and was shouted at that they are
needed for debugging, even though:

> >    As sorear has also pointed out: if we ever need to find the numeric
> >    value of an enum, gdb provides this functionality.

So many thanks for getting rid of this monstrosity.

> > commit 8e670811def5a5a43f7383f1f90e5169e8383637
> >    Wrap MONS_UNUSED_XXX in #if-preprocessor blocks.

Since there's a reason to bump the major[1], what about sorting the monsters
in some reasonable order?

> >    Leaving space "so people can slot monsters in <here>" doesn't really
> >    work because it doesn't seem to me that anyone really does this.

There is precisely one case where this matters: draconians.  And it's not
likely that we're going to add new colours or classes -- and even if we do,
we can then make a minor shim or bump the major.  Or go the old way and
leave a few blanks (with MONS_UNUSED, not =123 !).


[1]. If we do, it might be good to merge ench_split too -- there's a compat
shim but I don't fully understand Galehar's new skill training code so I'm
afraid of breaking it.


Meow.
-- 
1KB             // Microsoft corollary to Hanlon's razor:
                //      Never attribute to stupidity what can be
                //      adequately explained by malice.

------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Crawl-ref-discuss mailing list
Crawl-ref-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/crawl-ref-discuss

Reply via email to