Some notes on changes from Denizen to Denizen2.
- Thread starter mcmonkey
- Start date
mcmonkey said:
I'm not suggesting that the complicated and convoluted method of random text strings be maintained... the incremental numbering system is perfectly sufficient imo with the one caveat of having the originating script ID be the queue ID prefix.
mcmonkey said:
Because it's such a good idea that some genius dev decided that's how queues should be identified already... by name...
Anthony said:
Not only does that linked code go directly against your own point, you failed to make a fully qualified point in the first place! Good job!
Please present your own response or allow the relevant people to present their own answers.AbiDada said:
As was mentioned later in that channel, that response isn't particularly sufficient and was yelled in anger by annoyed users rather than well thought out.
My question stands:
WHY does having queue's prefixed with a script title help anything at all ever?
So that doesn't answer the whole "script title prefix" thing, but it does pose an alternate point which needs a response.Anthony said:
If I read you correctly, you want a way to determine rapidly if a queue for a certain process is already running.
There are a variety of better ways to do this than custom ID's.
Some examples include:
- (Best) Store a flag somewhere indicating the queue. If the flag is present and the queue held by the flag is valid and running, the process is running.
- (Alternate) Take the tag that returns a list of all queues, filter it for being run by the relevant script or containing other identifying data, and if you get back a list with one or more entries, you have both the queue and a reference to the queue.
A thing to consider when you're wanting queue ID's is this:
Can you give custom ID's to players? NPCs? /Anything/? No, you can't. You either leave a marker on them and search for the marker, or add them to an external named reference. What's wrong with doing the same for queue's?
Anthony said:
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.
In fact, writing your own specialized code would be /more/ efficient than a general for-all-queues name-based lookup table!
It is assumptive logic... specialized code that reduces general complexity is smart coding!
mcmonkey said:
I happily believe that your current idea is going to be most efficient for d2. But you have to take into account the main reason why denizen is used. use of ease.denizen is meant to be really easy to use and to do otherwise complex things with.
If you're going to strip the features that make it easy to use, to make it faster, you're making it more and more viable for users to instead directly program their own thing as a plugin rather than use denizen as a middle way.
Lets meet in the middle, and introduce a 'prefix' option for queue IDs, that are stored externally from queues, but still internally in d2 for the convenience of the scripter. this would only be optional and should only be affecting efficiency rates when actually utilized.
mcmonkey said:
me and anthony both use <queue.definitions> to return a complete list of arguments passed into a function. If we're going to have to filter out specific cases out of that list, every time, simply because we need an identifier, it again goes at cost of the user's ease of use and efficiency.
BlackCoyote said:
wh... why?
I can almost understand that in D1 (ALMOST) but in D2... where you can use a MapTag if you need a set of keys and values, ...?
mcmonkey said:
The maptag sounds like a neat thing, however it wouldn't work too great for API's wanting to make the user input as simple as possible. being able to pass 1|2|3 is a lot easier for the user than a=1|b=2|c=3. for some of us maptags might be extremely simple, but for beginners who need denizen because things otherwise get too complex, it is only pushing the bar up higher for them.
aditionally, a maptag would mean processing raw dlist inputs, for example <context.args> into a maptag or some sort, which would mean additional work and complexity for scripters.
If the input is just 1|2|3, then make the input .... 1|2|3, as a ListTag.BlackCoyote said:
I suggested a map tag cause I assumed you wanted definition names. If that's not needed, then just a simple list will fully suffice.
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.
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.