A separate callproc()() proc with DLL calling removed.

ID:2127524
 
Aug 6 2016, 7:56 am
Applies to:DM Language
Status: Open
Issue hasn't been assigned a status value.
I think the call()() proc tries to do too much. Calling external functions using the same proc that I would argue is primarily for calling local procs or verbs takes things way out of context.

There are currently three formats for call()():
1. call(ProcRef)(Arguments)
2. call(Object,ProcName)(Arguments) 
3. call(LibName,FuncName)(Arguments)


The issue is that format 2 is treated nearly the same as format 3 for the purpose of security checks. This leads me to avoid using this insecure proc, even though it has very useful functionality.

This is a request for copying formats 1 and 2 into something like a callproc()() proc. Attempting to use format 3 in callproc()() should result in a runtime error. I can imagine that the new callproc()() proc would have the side effect of being more efficient, since it wouldn't be doing as much as call()().

What this would mean for the original call()() is another issue, but it will have to keep its existing functionality to maintain compatibility. The reference should point out that it's safer to use callproc()() for calling procs, rather than call()().
Aug 6 2016, 9:45 am
I was experiencing a similar quirk when writing my Event library:
// something like this causes a security prompt at startup
call(listeners[id], callbacks[id])(arglist(args))

// but not this:
var listener = listeners[id]
call(listener, callbacks[id])(arglist(args))
Aug 6 2016, 11:42 am
In response to Kaiochao
I suspected there was something inconsistent about call()()'s behavior. That's why I get worried whenever I try to use it. Why are list items and variables treated differently? There's something very wrong about how external calls are detected or suspected.

I was also working on an event system, but that particular workaround didn't cross my mind. I would consider this more of a bug than a quirk. Even if it were fixed, I still think there would be some benefit to splitting up the proc. Normal proc calls already have enough overhead as it is. The overhead that call()() probably adds only makes things that much worse.