So let me see if I can combine the thoughts I've heard and make a proposal:
1. Split enum.h into two files. enum.h for game stuff and enum-for-tile-clients.h. 2. The client enum header file will contain valid enum's and #ifdefs, but no other variable declarations or prototypes. 3. Create a perl script to parse enum-for-tile-clients.h and create an enum-for-tile-clients.js 4. enum-for-tile-clients.js is the mapping of enum names to numbers to use for the Javascript client. 5. JSClientOutput.cc (code that will create Javascript description of GUI to be sent to Javascript client) will use numbers in place of enums. Let me know if this proposal works for everyone. It sounds o.k. to me, but my perl knowledge is not that great. Is there a volunteer to start the perl script? If someone can read the enum.h file into data structures, I can output the correct stuff. If not, I can muddle through it. :) --Jeff On Wed, May 4, 2011 at 5:05 AM, <crawl-ref-discuss-requ...@lists.sourceforge.net> wrote: > > Send Crawl-ref-discuss mailing list submissions to > crawl-ref-discuss@lists.sourceforge.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/crawl-ref-discuss > or, via email, send a message with subject or body 'help' to > crawl-ref-discuss-requ...@lists.sourceforge.net > > You can reach the person managing the list at > crawl-ref-discuss-ow...@lists.sourceforge.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Crawl-ref-discuss digest..." > > Today's Topics: > > 1. Re: Online Tiles - Data Format (Jeff Johnson) > 2. Re: Online Tiles - Data Format (Adam Borowski) > > > ---------- Forwarded message ---------- > From: Jeff Johnson <jeffjohns...@gmail.com> > To: crawl-ref-discuss@lists.sourceforge.net > Date: Tue, 3 May 2011 09:21:54 -0700 > Subject: Re: [Crawl-ref-discuss] Online Tiles - Data Format > If I have a perl script that creates the enum.h and a Javascript version > (enum.js), I'm not sure how to handle this: > > #if TAG_MAJOR_VERSION == 32 > > OBJ_UNKNOWN_I, // (use unknown) labeled as books in invent.cc {dlb} > > #endif > > With the enum macro business, this #if is easily handled. Also, if I send > the strings instead of the numbers the Javascript side doesn't need anything > from enum.h. It will just use the strings directly (e.g. if(item.base_type = > 'OBJ_WEAPON')). Only one file (jsclient.cc) needs to double include the .h > file since everyone else just needs the standard enum.h. All of the > non-jsclient files do not need to change. > > I concede there is a readability issue, but even if I have a enum-data.txt > file that I parse with a perl script, there is a minor readability issue and > a minor maintainability issue (.txt and .pl files to create a single .h). > > I think we should go with the enum macro solution, but if you still believe > we should go with a .txt and perl solution, could you suggest a file format? > Here was my initial idea: > > ENUM_IDENTIFIER: object_type_id > ENUM: OBJ_WEAPONS = 0 > ENUM: OBJ_MISSILES > ENUM: OBJ_ARMOUR > ENUM: OBJ_WANDS > ENUM: OBJ_FOOD > ENUM: OBJ_UNKNOWN_I > ... > ENUM: OBJ_GEMSTONES > ENUM: NUM_OBJECT_CLASSES > ENUM: OBJ_UNASSIGNED = 100 > ENUM: OBJ_RANDOM > ENUM: OBJ_DETECTED > END_ENUM: > > > --Jeff > > > On Tue, May 3, 2011 at 5:05 AM, > <crawl-ref-discuss-requ...@lists.sourceforge.net> wrote: >> >> Send Crawl-ref-discuss mailing list submissions to >> crawl-ref-discuss@lists.sourceforge.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.sourceforge.net/lists/listinfo/crawl-ref-discuss >> or, via email, send a message with subject or body 'help' to >> crawl-ref-discuss-requ...@lists.sourceforge.net >> >> You can reach the person managing the list at >> crawl-ref-discuss-ow...@lists.sourceforge.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Crawl-ref-discuss digest..." >> >> Today's Topics: >> >> 1. Re: Online Tiles - Data Format (Jeff Johnson) >> 2. Re: Online Tiles - Data Format (Adam Borowski) >> >> >> ---------- Forwarded message ---------- >> From: Jeff Johnson <jeffjohns...@gmail.com> >> To: crawl-ref-discuss@lists.sourceforge.net >> Date: Mon, 2 May 2011 13:01:46 -0700 >> Subject: Re: [Crawl-ref-discuss] Online Tiles - Data Format >> To handle the #if statements below, I decided to explore a different route. >> If I pass the enum's as strings as Robert suggests, I can avoid the issue. >> It provides a higher level of backwards compatibility and is slightly easier >> to maintain. >> >> I've created some Macros to wrap the enums and generate standard enums and a >> string map. The enums will look like this: >> >> DECLARE_ENUM (myenum) >> { >> ENUM_CONST(enum_1) >> ENUM_CONST_NUM(enum_2, 200) >> ENUM_CONST(enum_three) >> ENUM_END >> }; >> >> >> The standard enum macros will look like this: >> #define DECLARE_ENUM(x) enum x >> #define ENUM_CONST_NUM(x,n) x = n, >> #define ENUM_CONST(x) x, >> #define ENUM_END >> >> >> And the string map macros will look like this: >> #define DECLARE_ENUM(x) struct enum_strings_##x : std::map<unsigned int, >> std::string> { enum_strings_##x () >> #define ENUM_CONST_NUM(x,n) this->operator[]( x ) = # x; >> #define ENUM_CONST(x) this->operator[]( x ) = # x; >> #define ENUM_END } >> >> >> Are there are significant objections to this approach? Is there anyway to >> improve it? >> If not, I'll continue my slow pace towards Online Tiles in this direction. >> >> --Jeff >> >> >>> >>> ---------- Forwarded message ---------- >>> From: Robert Vollmert <rvollmert-li...@gmx.net> >>> To: crawl-ref-discuss@lists.sourceforge.net >>> Date: Wed, 27 Apr 2011 23:15:26 +0200 >>> Subject: Re: [Crawl-ref-discuss] Online Tiles - Data Format >>> >>> On Apr 27, 2011, at 23:12, Jeff Johnson wrote: >>> > For example there is this: >>> > #if TAG_MAJOR_VERSION == 32 >>> > OBJ_UNKNOWN_I, // (use unknown) labeled as books in invent.cc {dlb} >>> > #endif >>> >>> The enum value is to be removed, but not until save compatibility is broken >>> anyway by bumping TAG_MAJOR_VERSION. >>> >>> By the way, have you considered serializing these enum values as strings >>> (i.e., "unknown_i")? >>> >>> Cheers >>> Robert >>> >>> >>> >>> >> >> >> >> ---------- Forwarded message ---------- >> From: Adam Borowski <kilob...@angband.pl> >> To: crawl-ref-discuss@lists.sourceforge.net >> Date: Tue, 3 May 2011 00:49:33 +0200 >> Subject: Re: [Crawl-ref-discuss] Online Tiles - Data Format >> On Mon, May 02, 2011 at 01:01:46PM -0700, Jeff Johnson wrote: >> > To handle the #if statements below, I decided to explore a different route. >> > If I pass the enum's as strings as Robert suggests, I can avoid the issue. >> > It provides a higher level of backwards compatibility and is slightly >> > easier >> > to maintain. >> > >> > I've created some Macros to wrap the enums and generate standard enums and >> > a >> > string map. The enums will look like this: >> > >> > DECLARE_ENUM (myenum) >> > { >> > ENUM_CONST(enum_1) >> > ENUM_CONST_NUM(enum_2, 200) >> > ENUM_CONST(enum_three) >> > ENUM_END >> > }; >> > >> > >> > The standard enum macros will look like this: >> > #define DECLARE_ENUM(x) enum x >> > #define ENUM_CONST_NUM(x,n) x = n, >> > #define ENUM_CONST(x) x, >> > #define ENUM_END >> > >> > >> > And the string map macros will look like this: >> > #define DECLARE_ENUM(x) struct enum_strings_##x : std::map<unsigned int, >> > std::string> { enum_strings_##x () >> > #define ENUM_CONST_NUM(x,n) this->operator[]( x ) = # x; >> > #define ENUM_CONST(x) this->operator[]( x ) = # x; >> > #define ENUM_END } >> > >> > >> > Are there are significant objections to this approach? Is there anyway to >> > improve it? >> > If not, I'll continue my slow pace towards Online Tiles in this direction. >> >> I afraid that it would decrease code readability quite a bit. You'd need >> hacks with including a file twice, and the body of enums would look like: >> >> DECLARE_ENUM(monster_type) >> ENUM_CONST(MONS_SPRIGGAN) >> ENUM_CONST(MONS_SPRIGGAN_DRUID) >> ENUM_CONST_NUM(MONS_SPRIGGAN_ASSKICKER, 123) >> ENUM_CONST(MONS_SPRIGGAN_ASSASSIN) >> ENUM_END >> >> Also, the javascript code would have to carry its own redundant copy, that >> wouldn't get automatic updates and thus be likely to get out of sync. >> >> Thus, I really think generating the enum data with a script would be much >> better. The source could be either current enum.h, or from a plain list. >> We already auto-generate a good part of enums: all tile enums, MST_, >> unrands, command names, ... >> >> -- >> 1KB // Microsoft corollary to Hanlon's razor: >> // Never attribute to stupidity what can be >> // adequately explained by malice. >> >> >> >> ------------------------------------------------------------------------------ >> WhatsUp Gold - Download Free Network Management Software >> The most intuitive, comprehensive, and cost-effective network >> management toolset available today. Delivers lowest initial >> acquisition cost and overall TCO of any competing solution. >> http://p.sf.net/sfu/whatsupgold-sd >> _______________________________________________ >> Crawl-ref-discuss mailing list >> Crawl-ref-discuss@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/crawl-ref-discuss >> > > > > ---------- Forwarded message ---------- > From: Adam Borowski <kilob...@angband.pl> > To: crawl-ref-discuss@lists.sourceforge.net > Date: Wed, 4 May 2011 01:21:32 +0200 > Subject: Re: [Crawl-ref-discuss] Online Tiles - Data Format > On Tue, May 03, 2011 at 09:21:54AM -0700, Jeff Johnson wrote: > > If I have a perl script that creates the enum.h and a Javascript version > > (enum.js), I'm not sure how to handle this: > > > #if TAG_MAJOR_VERSION == 32 > > > OBJ_UNKNOWN_I, // (use unknown) labeled as books in invent.cc > > {dlb} > > > #endif > > > > With the enum macro business, this #if is easily handled. > > cpp enum.h > > > Also, if I send the strings instead of the numbers the Javascript side > > doesn't need anything from enum.h. It will just use the strings directly > > (e.g. if(item.base_type = 'OBJ_WEAPON')). Only one file (jsclient.cc) > > needs to double include the .h file since everyone else just needs the > > standard enum.h. All of the non-jsclient files do not need to change. > > So even using the preprocessor is not required. > > > I concede there is a readability issue, but even if I have a enum-data.txt > > file that I parse with a perl script, there is a minor readability issue and > > a minor maintainability issue (.txt and .pl files to create a single .h). > > A separate text file is not required, it's trivial to parse enum syntax. > > -- > 1KB // Microsoft corollary to Hanlon's razor: > // Never attribute to stupidity what can be > // adequately explained by malice. > > > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Crawl-ref-discuss mailing list > Crawl-ref-discuss@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/crawl-ref-discuss > ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ Crawl-ref-discuss mailing list Crawl-ref-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/crawl-ref-discuss
