View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000842 | LDMud 3.6 | LPC Language | public | 2015-08-07 05:21 | 2022-01-09 20:30 |
| Reporter | Bardioc | Assigned To | Gnomi | ||
| Priority | low | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 3.6.5 | ||||
| Summary | 0000842: Extend type saftey by adding class-name annotations to type 'object' for parameters and variables | ||||
| Description | While taking advantage of the new runtime type checks of LDMud 3.5.0.3, 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. Regards, Heiko aka Bardioc@Evermore | ||||
| Tags | No tags attached. | ||||
|
|
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: @require_living 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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-08-07 05:21 | Bardioc | New Issue | |
| 2016-06-20 21:46 | abathur | Note Added: 0002277 | |
| 2016-06-20 21:48 | abathur | Note Edited: 0002277 | |
| 2021-04-16 15:05 | Gnomi | Assigned To | => Gnomi |
| 2021-04-16 15:05 | Gnomi | Status | new => assigned |
| 2021-04-16 19:47 | zesstra | Project | LDMud => LDMud 3.6 |
| 2022-01-09 20:30 | Gnomi | Status | assigned => resolved |
| 2022-01-09 20:30 | Gnomi | Resolution | open => fixed |
| 2022-01-09 20:30 | Gnomi | Fixed in Version | => 3.6.5 |
