View Issue Details

IDProjectCategoryView StatusLast Update
0000842LDMud 3.6LPC Languagepublic2022-01-09 21:30
ReporterBardioc Assigned ToGnomi  
Status resolvedResolutionfixed 
Fixed in Version3.6.5 
Summary0000842: Extend type saftey by adding class-name annotations to type 'object' for parameters and variables
DescriptionWhile taking advantage of the new runtime type checks of LDMud, I've removed certain type checks we have implemented in methods during the years. While simply type checks are no longer necessary, I've came across a specific version. Let me explain this using an example:

public int make_em_die(object liv)
    check(liv, ({ IS_OBJECT, "/class/living/living" }))

    // make em actually die

I cannot remove this check here, as it is kind of an assertion that after the check line, 'liv' is supposed to be an instance of "/class/living/living". If someone calls this function with something else than an object that inherits "/class/living/living" the caller will get an error raised in the form:

Bad argument 1 to make_em_die(): expected 'instance of '/class/living/living''.

How about introducing something like the following within the driver that must be easily able to check this inheritance:

public int make_em_die(object["/class/living/living"] liv)
   // make em actually die

One could do this for variables too:

    object["/class/living/living"] liv = clone_object("/class/item/base/torch")
    // -> outch ... Wrong instance

What do you think of this? It would remove lots of checks in the mudlib code that needs to verify of the correct object has been given or created.


Heiko aka Bardioc@Evermore
TagsNo tags attached.



2016-06-20 23:46

reporter   ~0002277

Last edited: 2016-06-20 23:48

Just a few different thoughts/questions:

- Do you see benefits beyond just having this in core syntax? The syntax you suggest is shorter than your example, but it seems like you could also just define and use a simul_efun "require_living(liv)" and abstract that logic out without littering the mudlib with fixed paths?

- It seems like elevating this sort of object-identity test (versus an object functionality test) to core syntax might encourage some unfortunate over-restriction by suggesting these restrictions are a best practice? The syntax might, for example, inspire someone to make their container in/out functions require "treasure" objects, in the process making it so that a builder down the road would have to create new commands in order to build their dream quest where players have to smuggle Muffins the friendly gnome (an npc) through a guard post in their backpacks.

- In 0000817 I suggested bringing decorators to LPC; it doesn't look like we'll see them in the short term, but they could make for an interesting syntactical compromise that could enable the use of an lfun or sefun (or perhaps even an efun...) in a way that more clearly communicates that it is a precondition:

public int make_em_die(object liv){...}

- I was pondering the syntax you suggest for ways to shorten it, and I realized there's already a template here in how structs are handled. One alternative might be some sort of "object declaration" syntax along the lines of the struct and function declaration syntaxes, with the ability to create a short name that could fit into the same syntax idiom structs already use.

Issue History

Date Modified Username Field Change
2015-08-07 07:21 Bardioc New Issue
2016-06-20 23:46 abathur Note Added: 0002277
2016-06-20 23:48 abathur Note Edited: 0002277
2021-04-16 17:05 Gnomi Assigned To => Gnomi
2021-04-16 17:05 Gnomi Status new => assigned
2021-04-16 21:47 zesstra Project LDMud => LDMud 3.6
2022-01-09 21:30 Gnomi Status assigned => resolved
2022-01-09 21:30 Gnomi Resolution open => fixed
2022-01-09 21:30 Gnomi Fixed in Version => 3.6.5