ID:134181
 
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
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.
In response to CaptFalcon33035
What he's saying is that programmers could then specify "as null" in order to explicitly allow that possibility.
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
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.