starred/virtualtabletop

Fork 0

mirror of https://github.com/ArnoldSmith86/virtualtabletop.git synced 2026-03-02 22:57:02 -05:00

Routines need to be able to manipulate strings of numerals #275

New issue

Open

opened 2026-02-20 10:15:59 -05:00 by deekerman · 13 comments

deekerman commented

2026-02-20 10:15:59 -05:00

Owner

Originally created by @robartsd on GitHub (Jun 13, 2021).

Originally assigned to: @robartsd on GitHub.

Currently computations ALWAYS interpret strings of numerals as numbers. There needs to be ways to explicitly work with them as strings.

Originally created by @robartsd on GitHub (Jun 13, 2021). Originally assigned to: @robartsd on GitHub. Currently computations ALWAYS interpret strings of numerals as numbers. There needs to be ways to explicitly work with them as strings.

deekerman added the

bug

routine operations

needs legacy server

labels

2026-02-20 10:15:59 -05:00

deekerman commented

2026-02-20 10:16:00 -05:00

Author

Owner

@robartsd commented on GitHub (Jun 14, 2021):

An automatically generated id happened to be all numerals. 'idplaced in array by a routine and stored incardsPlayed` property. Stored property contained number instead of string. This select fails to capture the card.

    {
      "func": "SELECT",
      "property": "id",
      "relation": "in",
      "value": "${PROPERTY cardsPlayed}"
    }

@robartsd commented on GitHub (Jun 14, 2021): An automatically generated `id` happened to be all numerals. 'id` placed in array by a routine and stored in `cardsPlayed` property. Stored property contained number instead of string. This select fails to capture the card. ```json { "func": "SELECT", "property": "id", "relation": "in", "value": "${PROPERTY cardsPlayed}" } ```

deekerman commented

2026-02-20 10:16:00 -05:00

Author

Owner

@robartsd commented on GitHub (Jun 14, 2021):

I think the toNum conversion should be moved to be operation sensitive:

Should not convert to number:

+ (unless both operands can be converted)
Alphanumeric Comparisons (unless both operands can be converted)
arguments to string and array functions that are not explicitly numeric
object indexes

@robartsd commented on GitHub (Jun 14, 2021): I think the toNum conversion should be moved to be operation sensitive: Should not convert to number: - `+` (unless both operands can be converted) - Alphanumeric Comparisons (unless both operands can be converted) - arguments to string and array functions that are not explicitly numeric - object indexes

deekerman commented

2026-02-20 10:16:00 -05:00

Author

Owner

@ArnoldSmith86 commented on GitHub (Jun 14, 2021):

Changing that will be really ugly. The fileupdater would have to add it before nearly every operation...

@ArnoldSmith86 commented on GitHub (Jun 14, 2021): Changing that will be really ugly. The fileupdater would have to add it before nearly every operation...

deekerman commented

2026-02-20 10:16:00 -05:00

Author

Owner

@robartsd commented on GitHub (Jun 14, 2021):

Changing that will be really ugly. The fileupdater would have to add it before nearly every operation...

It needs to be fixed even if it breaks things.

@robartsd commented on GitHub (Jun 14, 2021): > Changing that will be really ugly. The fileupdater would have to add it before nearly every operation... It needs to be fixed even if it breaks things.

deekerman commented

2026-02-20 10:16:00 -05:00

Author

Owner

@ArnoldSmith86 commented on GitHub (Jun 14, 2021):

I don't agree. It should be fixed (or added) but we shouldn't break things.

@ArnoldSmith86 commented on GitHub (Jun 14, 2021): I don't agree. It should be fixed (or added) but we shouldn't break things.

deekerman commented

2026-02-20 10:16:00 -05:00

Author

Owner

@robartsd commented on GitHub (Jun 14, 2021):

I don't agree. It should be fixed (or added) but we shouldn't break things.

It needs to be fixed. If it can be fixed without breaking things that is great. If it can't be fixed without breaking things, then things break.

@robartsd commented on GitHub (Jun 14, 2021): > I don't agree. It should be fixed (or added) but we shouldn't break things. It needs to be fixed. If it can be fixed without breaking things that is great. If it can't be fixed without breaking things, then things break.

deekerman commented

2026-02-20 10:16:01 -05:00

Author

Owner

@robartsd commented on GitHub (Jun 14, 2021):

A possible fix that would not break things would be to add some way to switch mode between converting strings to numbers or not (defaulting to current behavior or using fileUpdater to override the new default).

This could be a new Boolean property in "func" blocks and a keyword on the LHS of dynamic expressions.

@robartsd commented on GitHub (Jun 14, 2021): A possible fix that would not break things would be to add some way to switch mode between converting strings to numbers or not (defaulting to current behavior or using fileUpdater to override the new default). This could be a new Boolean property in "func" blocks and a keyword on the LHS of dynamic expressions.

deekerman commented

2026-02-20 10:16:01 -05:00

Author

Owner

@ArnoldSmith86 commented on GitHub (Jun 14, 2021):

I mean, sure. But it can 100% be done without breaking stuff. The easiest solution would be to have a whole different set of operations.

A mode switch is already 100x better and maybe we find an even better solution.

@ArnoldSmith86 commented on GitHub (Jun 14, 2021): I mean, sure. But it can 100% be done without breaking stuff. The easiest solution would be to have a whole different set of operations. A mode switch is already 100x better and maybe we find an even better solution.

deekerman commented

2026-02-20 10:16:01 -05:00

Author

Owner

@robartsd commented on GitHub (Jun 14, 2021):

I mean, sure. But it can 100% be done without breaking stuff. The easiest solution would be to have a whole different set of operations.

A mode switch is already 100x better and maybe we find an even better solution.

I'd be okay if a mode switch turns off conversion to numbers completely, but I'd prefer conversion to number continue regardless of mode switch anywhere only a number would make sense.

Fortunately conversion from number to string happens automatically in many cases.

@robartsd commented on GitHub (Jun 14, 2021): > I mean, sure. But it can 100% be done without breaking stuff. The easiest solution would be to have a whole different set of operations. > > A mode switch is already 100x better and maybe we find an even better solution. I'd be okay if a mode switch turns off conversion to numbers completely, but I'd prefer conversion to number continue regardless of mode switch anywhere only a number would make sense. Fortunately conversion from number to string happens automatically in many cases.

deekerman commented

2026-02-20 10:16:01 -05:00

Author

Owner

@robartsd commented on GitHub (Jun 14, 2021):

Mode switch in Dynamic Expressions will be a small pain to write, simply because many (if not all) of the capturing indexes will change. Too bad named capture groups are probably not well enough supported for us to simply go with named capture groups as a more maintainable solution.

@robartsd commented on GitHub (Jun 14, 2021): Mode switch in Dynamic Expressions will be a small pain to write, simply because many (if not all) of the capturing indexes will change. Too bad named capture groups are probably not well enough supported for us to simply go with named capture groups as a more maintainable solution.

deekerman commented

2026-02-20 10:16:01 -05:00

Author

Owner

@ArnoldSmith86 commented on GitHub (Jun 14, 2021):

Yeah. I think we should list all the functions that would need a toggle (or always disabled). Then we add a mode toggle that defaults to "no conversion for those functions" and implement a fileupdater that adds the toggle at the start of every routine that uses one of those functions.

@ArnoldSmith86 commented on GitHub (Jun 14, 2021): Yeah. I think we should list all the functions that would need a toggle (or always disabled). Then we add a mode toggle that defaults to "no conversion for those functions" and implement a fileupdater that adds the toggle at the start of every routine that uses one of those functions.

deekerman commented

2026-02-20 10:16:01 -05:00

Author

Owner

@robartsd commented on GitHub (Jun 14, 2021):

Would we toggle at the routine level or the routine step level? At first I was thinking a flag in every step, but a step that changes the options might be nicer.

"...Routine": [
  "toNum: true",
  "var x = '100' // x gets set to 100",
  "toNum: false",
  "var y = '100' // y gets set to '100'"
]

@robartsd commented on GitHub (Jun 14, 2021): Would we toggle at the routine level or the routine step level? At first I was thinking a flag in every step, but a step that changes the options might be nicer. ```JSON "...Routine": [ "toNum: true", "var x = '100' // x gets set to 100", "toNum: false", "var y = '100' // y gets set to '100'" ] ```

deekerman commented

2026-02-20 10:16:01 -05:00

Author

Owner

@robartsd commented on GitHub (Jun 14, 2021):

We discussed in our meeting today about adding a mode switch to routines. To accommodate future changes we want a format that allows setting multiple modes in one line.

"...Routine": [
   "modes: autoConvertToNumber"
   ...current_behavior...
]

Another mode we mentioned would be for legacy setting default values of operands to 1.

@robartsd commented on GitHub (Jun 14, 2021): We discussed in our meeting today about adding a mode switch to routines. To accommodate future changes we want a format that allows setting multiple modes in one line. ```json "...Routine": [ "modes: autoConvertToNumber" ...current_behavior... ] ``` Another mode we mentioned would be for legacy setting default values of operands to `1`.

deekerman referenced this issue

2026-02-20 10:19:58 -05:00

RECALL should support recalling collections #715