(apememadide) Task and procs definitions type checking

[runic bison]

In some cases, I want to allow different input format for defintions.

One use case for it is I need to provide a script to a task that updates items. The idea is to store a script reference on the item scripts:

my_item:
  type: item
  ...
  data:
    refresh: my_item_refresh_script

# or 

my_item:
  type: item
  ...
  data:
    refresh: 
      script: all_items_refresh_scripts
      path: subscripts.my_specific_subtask

The other use case is for item lores. I want to be able to provide either a string (element) or list to my helper procedure:

my_item:
  type: item
  ...
  data:
    dynamic_lore: This lore is short. Works fine inline.

# or

my_item:
  type: item
  ...
  data:
    dynamic_lore: 
      - This lore is rather long,
      - and I need to insert a bunch of tag
      - in order to tell you that you own <player.flag[MONEY]>
      - and that your name is <player.name>

The only type checkers I found are is_boolean, and is_decimal|odd|even .

Is there any way to support that ?

[supple iron]

(apememadide) Task and procs definitions type checking

[supple iron]

Hi I'm AutoThreadBot! Don't mind me, I'll just be adding the helper team to this thread so they can see it. A human will get to you soon.

[glad prawn]

Why do you need type checking there? afaics you can just convert it with a fallback (e.g. for the lore input just make it into a list and if it fails then it isn't a list)

[runic bison]

Felt like it wasn't too clean to trigger an error + means having long ass tags

i.e.

handle_lore:
  type: procedure
  definitions: LORE
  script:
    - if <[LORE].is_list>:
      - determine <[LORE].separated_by[<n>]>
    - else:
      - determine <[LORE]>

seems pretty clean compared to

handle_lore:
  type: procedure
  definitions: LORE
  script:
    - determine <[LORE].separated_by[<n>].if_null[<[LORE]>]>

Readable at least

[glad prawn]

Why are you trying to make it space separated if you're setting it on an item

But also A. that looks fine imo, and B. if you want to you can

!t ObjectTag.as

[ancient halo]

Tag: <ObjectTag.as[<type>]>

Returns the object, automatically converted to the named object type.
Type names can be of the long form, like "ListTag", "MapTag", "ElementTag", ... or the short form, like "List", "Map", "Element", ...
Type name input is not case-sensitive, so "List" or "list" are the same.

Returns

ObjectTag

Examples

my_example:
    type: task
    # Some input can be any raw object type, but will be forced to a list using 'as[list]' below
    definitions: some_input
    script:
    - narrate "Input list has size <[some_input].as[list].size>"

[runic bison]

Also in this case is still looks okay, but it would actually be more complicated than separated_by[<n>]; I need to propagate colors etc

[glad prawn]

Make it into a list and do stuff on that

[runic bison]

what about the script thing?

[glad prawn]

But also you don't need to single-line it, can just

- define list <[input].as[list].if_null[null]>
- if <[list]> == null:
   - announce "Alert alert, bad item updater"
- do stuff

Or using a <list[]> constructor ofc

[runic bison]

- run <script[<[INPUT.SCRIPT]>].if_null[<script[<[INPUT]>]>]> path:<[INPUT.PATH].if_null[<empty>]>

vs:

- if <[INPUT].is_map>:
  - run <[INPUT.SCRIPT]> path:<[INPUT.PATH]>
- else:
  - run <[INPUT]>

I mean, considered the fact Denizen definitely knows the type, I'd consider it sensible to expose it similarly as as[map], i.e. is[map]

[willow current]

uhh

!t object_type

[ancient halo]

Tag: <ObjectTag.object_type>

Returns the short-form name of the tag type that is processing this tag, like 'List'.
This tag is made available to help you debug script issues, for example if you think an object isn't processing its own type correctly.

Returns

ElementTag

[runic bison]

!!!???!?!?!

[willow current]

Do you not know this exists or are you avoiding it?

[runic bison]

did not know it

thanks uwu

[lime oyster]

Resolved

Thread closed as resolved.

[willow current]

that was more a question to aya lol

[lime oyster]

Thread Reopened

Thread was manually reopened by @willow current.

[willow current]

oop

[glad prawn]

This tag is made available to help you debug script issues, for example if you think an object isn't processing its own type correctly.
It's not really meant to be used directly in a script & is generally a sign of bad practice

[runic bison]

how is code this clean bad practice

[willow current]

but like

[runic bison]

type checking is key to smooth handling

[willow current]

if you're just replicating it using more complicated methods

the same practice is there, it's just less clean

I always get confused when i see this lol

[glad prawn]

It depends, I'd say something like converting to a list and doing your logic is better then checking if it's a list or not and having 2 separate bits of logic

[willow current]

if a tag says not to use it, people just re-make the tag

[runic bison]

i mean you can convert an element to a list silently, but might need to actually distinguish the two

[glad prawn]

Especially if you eventually need a list (e.g. setting lore)

[runic bison]

you also can silently convert a map to an element, but it'll never be the output you wanted

so type checking Just This Great™️

(for the lore I actually didn't know it required a list so irrelevant now)

[glad prawn]

I.e. you can either have separate logic for lists or elements (more code, potentially even duplicate code) and Denizen converts it to a list later on anyway, or you can just make a list

[willow current]

ye, if it'll just become a list anyway, makes sense to do that while error checking

[runic bison]

but i mean, it would more like be

script:
- if <[def].object_type> == Element:
  - do some custom convertion to list
- now <[def]> is a list

the other way round, if it's a lore that receives an element, try to split it by new line

instead of just <[element].as[list]> and now you get a single entry list with newlines which will break

[willow current]

^ this is a very slightly cleaner way to do that

[runic bison]

nah because <[element].as[list]> would succeed, and you'd get newlines on your entry

[glad prawn]

For the script one, personally I'd do one line with script.sub.path/have a single set format (I.e map with potential path key) instead of a dynamic thing, but if you specifically want this format I suppose it'll always essentially be a type check yeah

[runic bison]

we can do - run script.sub.path ?

[glad prawn]

Yeah

[runic bison]

the more you know

[willow current]

<[element].as[list].parse[trim].if_null[null]> ?

[runic bison]

? does not split the newlines into entries

[willow current]

oh, that's what you want to do

yeah that could be tagified, but I think a type check is probably reasonable

[glad prawn]

Also object_type is often misleading, I.e. if you specify hi|there|Denizen somewhere, you might think you're specifying a list, but you're actually specifying an element Denizen converts into a list for you, e.g. any conversion logic you might have will get messed up

[runic bison]

i mean we could do element.as[list].parse[split[newlines]].flat (pseudo tagnames because i forgot what they are) but it becomes bloated and unclear

[glad prawn]

vs proper type conversions, which will do the making it into a list part

[runic bison]

but anyways, the subpath thing is fixed by the dot notation syntax and the lore proc is fixed since i need a list in the end so