Some notes on changes from Denizen to Denizen2.

[mcmonkey]

so you want me to make sure the end user passes the undefined list, as a single definition, and then have me, inside the script recieving that list, turn it back into individual definitions?
once again that becomes more work and makes denizen less user friendly than when we could just pass context[<dlist>] and have each argument ready as its own definition.

Why would you turn a properly constructed list into a series of definitions?

I'm so confused as to what your code setup even is.

 

[Anthony]

By requiring script names (as opposed to numeric IDs), you're creating an /internal/ lookup table... which, in D2, is no more efficient than an external one for most cases.

Why would having script names that are /not/ numerical necessitate the creation of a lookup table? Isn't there already a lookup table?

 

[BlackCoyote]

so you want me to make sure the end user passes the undefined list, as a single definition, and then have me, inside the script recieving that list, turn it back into individual definitions?
once again that becomes more work and makes denizen less user friendly than when we could just pass context[<dlist>] and have each argument ready as its own definition.

Why would you turn a properly constructed list into a series of definitions?

I'm so confused as to what your code setup even is.

assuming each value in that list is an individual argument, you would want to use it as such, rather than constantly retrieving it from the list whenever we need to call it.

additionally, this does not address what extra step the user has to provide to ensure the list is given as a single definition input, rather than just directly doing context[<list>] which would split each value as a definition

 

[mcmonkey]

By requiring script names (as opposed to numeric IDs), you're creating an /internal/ lookup table... which, in D2, is no more efficient than an external one for most cases.

Why would having script names that are /not/ numerical necessitate the creation of a lookup table? Isn't there already a lookup table?

Nope! There is just a list, which is then super rapidly searched without lookup table via numerical ID.

assuming each value in that list is an individual argument, you would want to use it as such, rather than constantly retrieving it from the list whenever we need to call it.

Huh?

additionally, this does not address what extra step the user has to provide to ensure the list is given as a single definition input, rather than just directly doing context[<list>] which would split each value as a definition

Here's sample D2 code: (Using a procedure as that seems to be what you're referencing)

# Ensure the definition 'arguments' is present. It is assumed to be a valid ListTag.
- require arguments
# Write to console the return of script "MyProc" with arguments input to the "args" definition (read from the "arguments" definition in our own queue as verified above)
- echo "<procedure[script:MyProc|args:<[arguments]>]>"
# At this point the console shows either an error message or a valid procedure return value for the input.

Straight forward, simple, no problems. :D Welcome to Denizen2!

 

[BlackCoyote]

so in d2, ANY argument given to a procedure script, will be returned as one list of arguments inside that procedure?

 

[Anthony]

Nope! There is just a list, which is then super rapidly searched without lookup table via numerical ID.

Ok so again, what's the difference between alphanumeric values in this list and strictly numeric values?

 

[mcmonkey]

so in d2, ANY argument given to a procedure script, will be returned as one list of arguments inside that procedure?

What? No 0.o

Let me give you another example.

- define list a|b|c
- define taco 1|2|3
- echo <procedure[script:MyProc|list:<[list]>|taco:<[taco]>|potato:eleven]>

You just ran 'MyProc' with 'list' as 'a|b|c' and 'taco' as '1|2|3' and 'potato' as 'eleven'

Note that the procedure would then access these as context variables. IE, <[context].

• >

• would return 'a|b|c'

 

[BlackCoyote]

I suppose I can't really argue much further about avoiding complexity when passing arguments, in order to maintain an identifier, when the new syntax for passed arguments already has a higher complexity enforced on default

 

[mcmonkey]

Ok so again, what's the difference between alphanumeric values in this list and strictly numeric values?

Ah I see the confusion now... too used to Denizen code and aren't aware of something that Denizen simplifies and abstractifies from the base Java.

In Denizen - if a == b and - if 1 == 2 are the same thing with different specific inputs.

In Java they are vastly different.

That's - if ("a".equals("b")) vs. if (1 == 2).

The important part is that the text is a complex and slow function call, whereas the numbers is a single machine code operation.

The concept of a lookup table is actually to convert text into numbers where possible for precisely this reason.

If all you have is numbers, you don't need a lookup table, because there's no way or reason to change numbers into numbers.

You have all the speed of the world's best lookup table and then some more speed, without any effort!

when the new syntax for passed arguments already has a higher complexity enforced on default

I don't think it's higher complexity, just different. How would we simplify this setup for scriptors without reducing all the advantages the new style gives us?

 

[BlackCoyote]

when the new syntax for passed arguments already has a higher complexity enforced on default

I don't think it's higher complexity, just different. How would we simplify this setup for scriptors without reducing all the advantages the new style gives us?[/quote]

allow passing arguments without identifying them, pretty much like the old setup, whilst leaving them with the identifier as an option. That would simplify it for scripters whilst maintaining the possibility to take the advantage of the new style

 

[BlackCoyote]

Ok so again, what's the difference between alphanumeric values in this list and strictly numeric values?

Ah I see the confusion now... too used to Denizen code and aren't aware of something that Denizen simplifies and abstractifies from the base Java.

allow us to specify the ID for the queue as an integer then? both problems solved?

 

[Anthony]

allow us to specify the ID for the queue as an integer then? both problems solved?

An 8 digit prefix lel

 

[mcmonkey]

when the new syntax for passed arguments already has a higher complexity enforced on default

I don't think it's higher complexity, just different. How would we simplify this setup for scriptors without reducing all the advantages the new style gives us?

allow passing arguments without identifying them, pretty much like the old setup, whilst leaving them with the identifier as an option. That would simplify it for scripters

How exactly is:
a|b|32|16|94|<def

• >|aleph

• 
  in any way simpler or more readable or more usable or better than:
  letter:a|system:b|value:32|height:16|limit:94|players:<def
  • >|name:aleph
  • 
    
    

    allow us to specify the ID for the queue as an integer then?

    That ruins the idea of it being a simple incrementing value (like what Citizens uses). And also doesn't solve any problem that I'm aware of?

 

[BlackCoyote]

allow us to specify the ID for the queue as an integer then? both problems solved?

An 8 digit prefix lel

it'd be better than nothing

 

[BlackCoyote]

How exactly is:
a|b|32|16|94|<def

• >|aleph

• 
  in any way simpler or more readable or more usable or better than:
  letter:a|system:b|value:32|height:16|limit:94|players:<def
  • >|name:aleph

• • 
    
    easier to read? no
    
    more usable? equally usable in most cases
    
    simpler? yes, when you're only passing one argument, or one list of arguments, you won't have to identify them, since you have no need to, you already know the purpose of the arguments

 

[mcmonkey]

simpler? yes, when you're only passing one argument, or one list of arguments, you won't have to identify them, since you have no need to, you already know the purpose of the arguments

Okay so you're proposing what new syntax exactly?

The current syntax, for reference, would be
<procedure[script:MyProc|arg:3]>

How would you format the new syntax, which is now being developed for the lone purpose of removing the piece "arg:" from that?

 

[BlackCoyote]

<proc[myproc].context[3]>

 

[mcmonkey]

<proc[myproc].context[3]>

You seem to be too caught up on Denizen1 syntax...


Among other things, that doesn't even work within the D2 engine, where one tag = one tag, rather than two tags forming a single tag for some random reason.

It's also ugly syntax.

It also doesn't support paths.

It's also randomly longer than necessary.

Like it's all around terrible in all ways except the "compatibility with old code" way.

 

[mcmonkey]

Point 15 added.

 

[BlackCoyote]

what about a speed argument in script containers?