Feature - Implemented Make to_int(<type>) and to_<type>(int) consistently reversible for all possible types

[zarqon]

Make to_int(<type>) and to_<type>(int) consistently reversible for all possible types

Presently, there are integers associated with most of the ASH plural typed constants, as revealed by to_int():

to_int(item) : yes
to_int(location) : no
to_int(monster) : no
to_int(element) : yes
to_int(familiar) : yes
to_int(skill) : yes
to_int(effect) : yes
to_int(stat) : yes
to_int(class) : yes
to_int(coinmaster) : no
to_int(phylum) : yes

So, aside from locations, monsters, and coinmasters, all the ASH typed constants have associated integers. Where associated integers exist, I think most scripters would expect casting functions to exist in both directions. However, this is not consistently the case:

to_item(int) : yes
to_element(int) : no
to_familiar(int) : yes
to_skill(int) : yes
to_effect(int) : yes
to_stat(int) : no
to_class(int) : no
to_phylum(int) : no

> ash foreach i in $elements[] print(to_int(i)+" : "+i)

1 : cold
2 : hot
3 : sleaze
4 : spooky
5 : stench
6 : slime
Returned: void

> ash to_element(3)

Returned: none

So, I am requesting that to_<type>(int) be made to work for elements, stats, classes, and phyla. I had actually used some of these functions, assuming that since to_int(type) worked that to_type(int) would work as well, but my integers were evidently being silently cast to strings, causing the functions to always return $type[none] -- and confusing me greatly until I realized what was going on.

 

[holatuwol]

10684.

 

[zarqon]

Ridiculously fast!! Thanks!

 

[Veracity]

Now, see, what I would have done is remove the following:

to_int(element) : yes
to_int(stat) : yes
to_int(class) : yes
to_int(phylum) : yes

because there is no "natural" number associated with them in KoL itself, unlike items, effects, skills, and familiars. For those last 4, you can use the integer for constructing URLs that apply to the object. For the other ones that have to_int(), we return an arbitrarily chosen number with no inherent meaning. That's why we didn't bother making to_int() for monsters, locations, and coinmasters. Providing it for stat, class, element, and phylum was a mistake.

I might write a Feature Request suggesting that we fix that by removing the meaningless type_to_int and int_to_type pairs.

 

[zarqon]

It may have been a mistake, but it was a handy one. For example, BatBrain parses substats information from its data file using strings formatted as "a|b|c", then foreaches a split_string, assigning each integer to to_stat(index+1).

Integers are easy to work with and allow < and > comparisons, and other useful operators which can isolate or remove ranges from consideration by a foreach loop. While the integers are arbitrary, they are not meaningless. Please retain them.

 

[Veracity]

Integers allow < and >, yes - but what does that mean for an element, say? Is sleaze > stench?

You like to use to_stat( int ) for reading from data files. You "know" that Muscle is #1, Mysticality is #2, and Moxie is #3, and put the fields in your data file in the order Muscle, Mysticality, and Moxie. Now, I go and change the order of the table in ASH and make Mysticality #1, Moxie #2, and Muscle #3. Why shouldn't I? The numbers are completely arbitrary. The built-in to_stat() function works just as well as before, in that it will translate a number to a stat - but it's not the number you expected. Doesn't it seem like you'd really prefer to have your own to_stat() function which translates integers to stats in the order that you are counting on?

I'd like some solid examples of why KoLmafia itself needs to provide these mapping functions.

 

[Fluxxdog]

I'd like some solid examples of why KoLmafia itself needs to provide these mapping functions.

I don't think you're going to get solid. In fact, the only solid example was classes. Stats may have been arbitrary, but it was reliable and has been used as a standard. Removing the integer conversion for stats will likely break some scripts, but there is no real basis for keeping them hard coded in mafia. And considering you're only removing 3 numbers, the fix shouldn't be that difficult.