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, <
[email protected]> wrote:
> Send Crawl-ref-discuss mailing list submissions to
> [email protected]
>
> 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
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> 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 <[email protected]>
> To: [email protected]
> 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 <[email protected]>
>> To: [email protected]
>> 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 <[email protected]>
> To: [email protected]
> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/crawl-ref-discuss
