Some notes on changes from Denizen to Denizen2.

Discuss plans for the development of Denizen2Sponge here.
User avatar
mcmonkey
Site Admin
Site Admin
Posts: 201
Joined: August 5th, 2016, 7:27 pm
Location: Los Angeles, California, USA
Contact:

Re: Some notes on changes from Denizen to Denizen2.

Post by mcmonkey » August 12th, 2016, 10:00 am

BlackCoyote wrote: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.
Denizen lead developer.
http://mcmonkey.org

Anthony
Regular
Regular
Posts: 35
Joined: August 5th, 2016, 9:01 pm

Re: Some notes on changes from Denizen to Denizen2.

Post by Anthony » August 12th, 2016, 10:02 am

mcmonkey wrote: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?
We are the music makers, and we are the dreamers of dreams...

BlackCoyote
Regular
Regular
Posts: 78
Joined: August 6th, 2016, 1:44 am

Re: Some notes on changes from Denizen to Denizen2.

Post by BlackCoyote » August 12th, 2016, 10:03 am

mcmonkey wrote:
BlackCoyote wrote: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

User avatar
mcmonkey
Site Admin
Site Admin
Posts: 201
Joined: August 5th, 2016, 7:27 pm
Location: Los Angeles, California, USA
Contact:

Re: Some notes on changes from Denizen to Denizen2.

Post by mcmonkey » August 12th, 2016, 10:08 am

Anthony wrote:
mcmonkey wrote: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.
BlackCoyote wrote: 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?
BlackCoyote wrote: 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)

Code: Select all

# 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!
Denizen lead developer.
http://mcmonkey.org

BlackCoyote
Regular
Regular
Posts: 78
Joined: August 6th, 2016, 1:44 am

Re: Some notes on changes from Denizen to Denizen2.

Post by BlackCoyote » August 12th, 2016, 10:11 am

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

Anthony
Regular
Regular
Posts: 35
Joined: August 5th, 2016, 9:01 pm

Re: Some notes on changes from Denizen to Denizen2.

Post by Anthony » August 12th, 2016, 10:12 am

mcmonkey wrote: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?
We are the music makers, and we are the dreamers of dreams...

User avatar
mcmonkey
Site Admin
Site Admin
Posts: 201
Joined: August 5th, 2016, 7:27 pm
Location: Los Angeles, California, USA
Contact:

Re: Some notes on changes from Denizen to Denizen2.

Post by mcmonkey » August 12th, 2016, 10:14 am

BlackCoyote wrote: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.

Code: Select all

- 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].[list]> would return 'a|b|c'
Denizen lead developer.
http://mcmonkey.org

BlackCoyote
Regular
Regular
Posts: 78
Joined: August 6th, 2016, 1:44 am

Re: Some notes on changes from Denizen to Denizen2.

Post by BlackCoyote » August 12th, 2016, 10:18 am

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

User avatar
mcmonkey
Site Admin
Site Admin
Posts: 201
Joined: August 5th, 2016, 7:27 pm
Location: Los Angeles, California, USA
Contact:

Re: Some notes on changes from Denizen to Denizen2.

Post by mcmonkey » August 12th, 2016, 10:20 am

Anthony wrote: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!
BlackCoyote wrote: 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?
Denizen lead developer.
http://mcmonkey.org

BlackCoyote
Regular
Regular
Posts: 78
Joined: August 6th, 2016, 1:44 am

Re: Some notes on changes from Denizen to Denizen2.

Post by BlackCoyote » August 12th, 2016, 10:22 am

BlackCoyote wrote: 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
Last edited by BlackCoyote on August 12th, 2016, 10:25 am, edited 1 time in total.

BlackCoyote
Regular
Regular
Posts: 78
Joined: August 6th, 2016, 1:44 am

Re: Some notes on changes from Denizen to Denizen2.

Post by BlackCoyote » August 12th, 2016, 10:23 am

mcmonkey wrote:
Anthony wrote: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
Regular
Regular
Posts: 35
Joined: August 5th, 2016, 9:01 pm

Re: Some notes on changes from Denizen to Denizen2.

Post by Anthony » August 12th, 2016, 10:25 am

BlackCoyote wrote:allow us to specify the ID for the queue as an integer then? both problems solved?
An 8 digit prefix lel
We are the music makers, and we are the dreamers of dreams...

User avatar
mcmonkey
Site Admin
Site Admin
Posts: 201
Joined: August 5th, 2016, 7:27 pm
Location: Los Angeles, California, USA
Contact:

Re: Some notes on changes from Denizen to Denizen2.

Post by mcmonkey » August 12th, 2016, 10:26 am

BlackCoyote wrote:
mcmonkey wrote:
BlackCoyote wrote: 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[list]>|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[list]>|name:aleph
BlackCoyote wrote: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?
Denizen lead developer.
http://mcmonkey.org

BlackCoyote
Regular
Regular
Posts: 78
Joined: August 6th, 2016, 1:44 am

Re: Some notes on changes from Denizen to Denizen2.

Post by BlackCoyote » August 12th, 2016, 10:26 am

Anthony wrote:
BlackCoyote wrote: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
Regular
Regular
Posts: 78
Joined: August 6th, 2016, 1:44 am

Re: Some notes on changes from Denizen to Denizen2.

Post by BlackCoyote » August 12th, 2016, 10:29 am

mcmonkey wrote: How exactly is:
a|b|32|16|94|<def[list]>|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[list]>|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

User avatar
mcmonkey
Site Admin
Site Admin
Posts: 201
Joined: August 5th, 2016, 7:27 pm
Location: Los Angeles, California, USA
Contact:

Re: Some notes on changes from Denizen to Denizen2.

Post by mcmonkey » August 12th, 2016, 10:31 am

BlackCoyote wrote: 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?
Denizen lead developer.
http://mcmonkey.org

BlackCoyote
Regular
Regular
Posts: 78
Joined: August 6th, 2016, 1:44 am

Re: Some notes on changes from Denizen to Denizen2.

Post by BlackCoyote » August 12th, 2016, 10:32 am

<proc[myproc].context[3]>

User avatar
mcmonkey
Site Admin
Site Admin
Posts: 201
Joined: August 5th, 2016, 7:27 pm
Location: Los Angeles, California, USA
Contact:

Re: Some notes on changes from Denizen to Denizen2.

Post by mcmonkey » August 12th, 2016, 10:35 am

BlackCoyote wrote:<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.
Denizen lead developer.
http://mcmonkey.org

User avatar
mcmonkey
Site Admin
Site Admin
Posts: 201
Joined: August 5th, 2016, 7:27 pm
Location: Los Angeles, California, USA
Contact:

Re: Some notes on changes from Denizen to Denizen2.

Post by mcmonkey » August 14th, 2016, 1:24 am

Point 15 added.
Denizen lead developer.
http://mcmonkey.org

BlackCoyote
Regular
Regular
Posts: 78
Joined: August 6th, 2016, 1:44 am

Re: Some notes on changes from Denizen to Denizen2.

Post by BlackCoyote » August 14th, 2016, 7:23 am

what about a speed argument in script containers?

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest