|Anonymous | Login | Signup for a new account||2019-01-23 16:34 PST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000129||Core Inform||Kinds and type checking||public||2010-06-25 16:34||2010-11-30 08:05|
|Platform||x86||OS||Mac OS X||OS Version||10.4|
|Target Version||Fixed in Version||6F95|
|Summary||0000129: Missing run-time type check assigning from a supertype to a subtype|
|Description||Inform should insert a run-time type check at assignments where it cannot guarantee type safety. The attached code, for instance, takes advantage of the implicit typing of ``dim spot'' (a local object variable) to store scenery in a global declared as holding a room.|
|Minimal Source Text To Reproduce|
There is a room. The place of origin is a room that varies. The shadows are scenery. When play begins: let a dim spot be the shadows; now the place of origin is a dim spot; move the player to the place of origin.
|Tags||No tags attached.|
|Effect||(serious/mild) Game compiles but misbehaves|
Ron Newcomb (reporter)
Isn't this issue with the "move the player to.." command, which does exactly what it is told, no questions asked? As opposed to "now the player is in..." which *does* ask questions?
I am under the impression that "move..to..." is directly exposing an old Inform6 function not unlike the I6 testing command ABSTRACT... TO...
now the player is in the place of origin.
for the last line has no effect on the story output.
The issue is that "the place of origin" is always supposed to refer to a room. Inform gives a compile-time error if you say "The place of origin is the shadows", or if you set it directly at runtime with "now the place of origin is the shadows", but still allows you to set it by using a temporary variable with a broader type. That is, Inform knows it can't store a thing in a room variable, but assumes it can always store an object in a room variable, even though not all objects are rooms.
"move the player to the place of origin" is kind of a red herring here, since "move" is defined as taking two objects. You can just write "move the player to the shadows" independently of this bug.
Fixed; Inform now inserts the necessary code to perform the check at run-time. This test source, for example, produces the run-time problem message:
Attempt to set a variable to the wrong kind of object: you wrote 'now the place of origin is a dim spot', which sets the value to the shadows - but that doesn't have the kind 'room'.
|2010-06-25 16:34||EmacsUser||New Issue|
|2010-06-25 16:36||jmcgrew||Severity||mild => serious|
|2010-06-25 16:36||jmcgrew||Status||new => acknowledged|
|2010-06-25 20:03||jmcgrew||Status||acknowledged => confirmed|
|2010-07-01 00:44||jmcgrew||Severity||serious => mild|
|2010-07-06 13:36||Ron Newcomb||Note Added: 0000252|
|2010-07-06 14:43||EmacsUser||Note Added: 0000253|
|2010-07-06 16:39||jmcgrew||Note Added: 0000255|
|2010-09-27 12:20||graham||Note Added: 0000602|
|2010-09-27 12:20||graham||Status||confirmed => resolved|
|2010-09-27 12:20||graham||Resolution||open => fixed|
|2010-09-27 12:20||graham||Assigned To||=> graham|
|2010-10-25 21:14||jmcgrew||Fixed in Version||=> 6F95|
|2010-10-28 00:30||jmcgrew||Status||resolved => closed|
|2010-11-30 08:05||EmacsUser||Issue cloned||0000445|
|2010-11-30 09:01||jmcgrew||Relationship added||related to 0000445|
|2011-12-07 09:57||EmacsUser||Relationship added||related to 0000809|
|Copyright © 2000 - 2010 MantisBT Group|