smart command queuing please in Feature Requests

ID:134181
 
Mar 25 2007, 9:21 am
Status: Open
Issue hasn't been assigned a status value.
Regarding the problem described here:
[link]

Basically, can't it be changed so if at the time Dream Seeker actually sends the command, one of the arguments which aren't set with input type as null IS null, the command is aborted? Programmers shouldn't have to manually check for that in their verbs.
if this has been implemented, smack me please
#1 Mar 25 2007, 3:17 pm
I think it's just fine the way it is.

Besides, sometimes if you can't find an atom in some location, instead of stopping the procedure, you may want to do something else. I think a lot of games use this functionality.
#2 Mar 26 2007, 2:30 am
In response to CaptFalcon33035 (#1)
What he's saying is that programmers could then specify "as null" in order to explicitly allow that possibility.
#3 Mar 26 2007, 7:02 am
Kaioken wrote:
Regarding the problem described here:
[link]

Basically, can't it be changed so if at the time Dream Seeker actually sends the command, one of the arguments which aren't set with input type as null IS null, the command is aborted? Programmers shouldn't have to manually check for that in their verbs.

As it is, other things like whether an obj is still in oview(1) need to be manually checked (but often aren't), and that would be much harder to catch and absorb. Improving one aspect of this while leaving the others would be inconsistent behavior. Also, there is the slight matter of allowing verbs to be called as procs, where overriding the default restrictions might be important, so the check would have to happen somehow before the actual verb code was called.

This might be doable, but it is not presently feasible.

Lummox JR
#4 Dec 20 2012, 7:46 am
Bump. If this is now feasible, it seems to me like a good idea to do, since it'd slightly improve the language (prevent error messages/necessity for certain failchecks) and Dream Seeker/Dream Daemon efficiency.

Lummox JR wrote:
As it is, other things like whether an obj is still in oview(1) need to be manually checked (but often aren't), and that would be much harder to catch and absorb. Improving one aspect of this while leaving the others would be inconsistent behavior.

IMO, in contrast to whether an obj is still within oview() or not, I'd suppose it would be correct to make a general presumption that if said strictly required obj is no longer in existence at all, then the verb call shouldn't even be fired. And I'd hazard a guess that such a thing would be easier for Dream Seeker to do.
I might not remember everything about this right now. As a reminder to me and you, if the obj isn't strictly required, then the verb would specify it with as obj|null rather than with as obj.

N.B. guess this needs to move to Feature Requests.