View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000763 | LDMud 3.5 | Runtime | public | 2010-11-11 17:37 | 2018-01-30 04:59 |
| Reporter | zesstra | Assigned To | Gnomi | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Platform | x86_64 | OS | MacOS X | OS Version | 10.5.x |
| Fixed in Version | 3.5.0 | ||||
| Summary | 0000763: Introduce pragma to downgrade RTTC errors to warnings | ||||
| Description | Xtian on ldmud-talk expressed the wish to convert the errors raised during RTT checks into warnings to ease the conversion/transition process. While I don't like to downgrade the errors to warnings in general, an additional pragma would be OK. | ||||
| Additional Information | http://mail63.csoft.net/pipermail/ldmud-talk/2010-November/000212.html http://mail63.csoft.net/pipermail/ldmud-talk/2010-November/000214.html Hello World, On 11.11.10 11:51, xtian wrote: > > When you enable run time type checks (these are rather new in the 3.5 > > branch) the driver throws fully-fledged errors when it encounters an > > invalid type. There are three reasons this being errors instead of warnings: If you use type checks (strong_/strict_types, the compile-time equivalent of rtt_checks), the compiler will regard incompatible types as errors. My opinion is, that it should also be an error at runtime for consistency reasons - it is still a programming error. (I know LPC was basically type-less - that is not the point here because the programmer explicitly requested typechecks.) Second reason is that if a programmer requests a specific type and enables the RTTC, she relies on receiving only compatible types and usually does not bother with own typechecks. If that assumption is not true, the programmers code will probably fail at some point. Therefore I have to keep my own checks if there are only warning upon incompatible types. Third reason is my experience, that very few people take warnings serious and the vast majority just ignores them. That being the rationale for throwing errors - but please stay with me until the end of this mail. > > Now we (avalon) tried that out on a few corelib files and always hat to > > revert rather quickly because - well we were flooded with errors and > > players just couldn't continue playing normally. So for us, at the moment, > > throwing errors does hinder adaption of this new feature. And I was rather > > looking forward to using the checks generously. We had similar experience when enabling strong_types+save_types in the corelib - it took me several months of testing and fixing in my homemud until I could enable them for good in MorgenGrauen. In case of the RTTC I enabled them in my homemud and used a kind lib tester (It loads every known object, clones them if suitable and moves some testplayers into every room, looking at all the details in them... Not bulletproof, but very handy nonetheless). After that we could enable them for real - there were errors, but not too many to handle them. > > Enabling RTTC in an testing environment will never catch all the problems, > > so players will always stumble over such an error - and for them something > > will thus not work. Yes. There is nothing better for testing than real players. I think, it is acceptable for players to encounter the one or other bug, if they are dealt with quickly and it does not happen too often. We therefore accept a certain amount of false-negatives. (I accept that you might have other demands in your mud, just wanted to add my point of view.) > > In short, throwing errors (for a language change or enhancement) is not > > suitable for a productive environment. No mud (I know of) is a pure 'productive environment'. There is always more or less development in the live mud and there are always errors in presence of players. > > I would much rather have the RTTC throw warnings. (the mudlib can always > > convert them to errors if it likes). This gives the wizards all the time > > they need to correct code while not interrupting normal gameply. For mainly the first two reasons given above I would definitely not like to raise only warnings during the RTTC. But I see your wish for a smoother transition if you are confident that warnings are sufficient in your mud. But instead of an optional pragma which optionally upgrades warnings to errors I suggest an optional pragma which reduces the errors to warnings. You then may still apply domain-specific combinations of rtt_checks and rttc_onlywarn in the autoinclude hook and remove the downgrading pragma once you feel confident (hopefully soon ;-) ). Side note: I feel not too good about using sloppy/pedantic for this purpose, because it enables errors I might not really want to have if I only want to have consistent type checks and rely on compatible argument/return types. Or to put it differently: for having a usable enforcement of types I should not have to buy a whole different class of errors as well. The warnings pedantic changes to errors are really a lot _less_ serious than invalid types when the programmer wants to have only compatible types. Bye, Zesstra@MG | ||||
| Tags | No tags attached. | ||||
|
|
I am afraid, I won't find time for this too soon. So if anybody else wants to work on it, please feel free. Note: It is not as simple as it looks (set a flag, call warnf instead of errorf), because the stuff manipulates the stack to get to the needed information and that can't be done in case of warnings. It therefore requires some more changes. |
|
|
Fix committed in revision a3089ceb747b8b996cb5222549c9424369211f92 to master branch (see changeset 1144 for details). Thank you for reporting! |
|
|
Fix committed in revision a3089ceb747b8b996cb5222549c9424369211f92 to master branch (see changeset 1208 for details). Thank you for reporting! |
|
|
Fix committed in revision a3089ceb747b8b996cb5222549c9424369211f92 to master branch (see changeset 2410 for details). Thank you for reporting! |
|
|
Fix committed in revision a3089ceb747b8b996cb5222549c9424369211f92 to master branch (see changeset 2531 for details). Thank you for reporting! |
|
|
Fix committed in revision a3089ceb747b8b996cb5222549c9424369211f92 to master branch (see changeset 2412 for details). Thank you for reporting! |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-11-11 17:37 | zesstra | New Issue | |
| 2010-11-11 17:37 | zesstra | Status | new => assigned |
| 2010-11-11 17:37 | zesstra | Assigned To | => zesstra |
| 2011-11-22 11:06 | zesstra | Assigned To | zesstra => |
| 2011-11-22 11:09 | zesstra | Note Added: 0002084 | |
| 2011-11-22 11:09 | zesstra | Status | assigned => acknowledged |
| 2011-11-22 11:09 | zesstra | Target Version | 3.5.0 => |
| 2016-11-28 20:06 | Gnomi | Assigned To | => Gnomi |
| 2016-11-28 20:06 | Gnomi | Status | acknowledged => assigned |
| 2017-09-30 18:04 | Gnomi | Status | assigned => resolved |
| 2017-09-30 18:04 | Gnomi | Resolution | open => fixed |
| 2017-09-30 18:04 | Gnomi | Fixed in Version | => 3.5.0 |
| 2018-01-28 22:31 | Source_changeset_attached | => ldmud.git master a3089ceb | |
| 2018-01-28 22:31 | zesstra | Note Added: 0002295 | |
| 2018-01-29 19:59 | Gnomi | Source_changeset_attached | => ldmud.git master a3089ceb |
| 2018-01-29 19:59 | Gnomi | Note Added: 0002302 | |
| 2018-01-29 20:34 | Gnomi | Source_changeset_attached | => ldmud.git master a3089ceb |
| 2018-01-29 20:34 | Gnomi | Note Added: 0002348 | |
| 2018-01-29 22:57 | Gnomi | Source_changeset_attached | => ldmud.git master a3089ceb |
| 2018-01-29 22:57 | Gnomi | Note Added: 0002353 | |
| 2018-01-30 04:59 | Gnomi | Source_changeset_attached | => ldmud.git master a3089ceb |
| 2018-01-30 04:59 | Gnomi | Note Added: 0002404 |
