Regarding Stddef.dm

ID:1879338
 
Jun 21 2015, 10:57 pm
I noticed that there are multiple 'alias' functions in the Stddef, and I'm curious as to why. At first, I thought "Well, it references an additional variable.."
Then, I realized there are(ahem, should be) much more efficient methods of actually doing the same. I honestly don't see what the purpose is in not using the original function in the first place. What would be the point of this, or something similar in say.. a parser?

Also wondering if the new access to Appearances will change the stddef, but that's not really on-topic/doesn't have anything to do with design decisions.

Edit:
Er, just to clarify, I'm referring to this.
       Flip(dir)
            _dm_flip_icon(icon,dir)
        Shift(dir,offset,wrap)
            _dm_shift_icon(icon,dir,offset,wrap)
        SetIntensity(r,g=-1,b=-1)
            _dm_icon_intensity(icon,r,g,b)
        Blend(icon,f,x=1,y=1)
            _dm_icon_blend(src.icon,icon,f,x,y)
        SwapColor(o,n)
            _dm_icon_swap_color(icon,o,n)
        DrawBox(c,x1,y1,x2,y2)
            _dm_icon_draw_box(icon,c,x1,y1,x2,y2)
        Insert(new_icon,icon_state,dir,frame,moving,delay)
            _dm_icon_insert(icon,new_icon,icon_state,dir,frame,moving,delay)
Jun 22 2015, 2:59 am
Well the main advantage to Lummox is it's a known API. He can replace all of those private functions with a completely different strategy in the future (perhaps procs on /icon, or some all-in-one replacement) without breaking the API everyone is compiling against. Likewise if new features essentially boil down to a Flip() call plus some extra arguments, he can refactoring _dm_flip_icon() to accept the extra arguments and just default the ones for Flip() as appropriate.
Jun 22 2015, 3:50 am
At some point, I guess it became simpler to provide hooks to basic functions, and simply softcode their behavior within an atom.
Jun 22 2015, 8:36 am
The icon code is sort of an older way of doing things, in that it's basically aliasing many internal functions instead of few. I've moved away from that approach as you can see in /matrix an /database.

The reason those functions are internal for /icon is because the datum is there to wrap around a more "raw" object that represents the internal mutable icon. But the fact that there are so many of them bothers me on a lot of levels. (Sure I contributed to the problem, but I kept the design consistent.)

For /database and /matrix I went a different route using a catch-all function instead. The main advantage to that is that it's more malleable, and also it doesn't clog up the proc code with more possible instructions; instead pretty much everything routes through one function.

As you can see in the /matrix code, the underlying matrix() function is extremely versatile. You can pass it six args for a raw matrix, or you can pass something like matrix(60,MATRIX_ROTATE).

To answer your question about appearance, that didn't change stddef.dm but the new /exception datum and associated macro did. The new datum was needed because people requested, with the new try/catch, a way of tracking line number info as well as the runtime error itself.