| Anonymous | Login | Signup for a new account | 2010-09-06 00:09 EDT |
| Main | My View | View Issues | Change Log | Roadmap | Docs |
| Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||
| ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||
| 0000045 | [TADS 3] Library - Adv3 | tweak | always | 2009-02-07 17:47 | 2009-02-14 19:48 | ||
| Reporter | Carlo | View Status | public | ||||
| Assigned To | Michael Roberts | ||||||
| Priority | normal | Resolution | fixed | ||||
| Status | resolved | ||||||
| Summary | 0000045: Settable.actionDobjSetTo evaluates okaySetToMsg too early | ||||||
| Description |
The line defaultReport(okaySetToMsg, curSetting); should be changed to defaultReport(&okaySetToMsg, curSetting); Otherwise, it is not possible to directly define okaySetToMsg(val) on my Settable object, since the above line then complains about "wrong number of arguments". I can still work around this by doing okaySetToMsg = &okaySetToMsg_ okaySetToMsg(val) { return 'set to ' + val ' kthx'; } for example. (Currently I solve the problem by just "modify"ing Settable.actionSetToMsg.) |
||||||
| Additional Information | |||||||
| Tags | No tags attached. | ||||||
| Fixed In Version | 3.0.18 | ||||||
| Attached Files | |||||||
|
|
|||||||
 Relationships |
|
|
Notes |
|
|
(0000084) Michael Roberts (administrator) 2009-02-13 01:25 |
This was actually intentional, although I agree that it's not consistent with the usual pattern. The reason it evaluates the property directly is that the okaySetToMsg property itself yields an &okaySetToMsg pointer, which points to the actual message - convoluted, I know. The benefit is that subclasses of Settable (such as Dial) can override okaySetToMsg to yield a different library message property. But it does break the usual convention for local message overrides. I think the solution is to change the name of the intermediate property that everyone's overriding - something like this: Settable: ... action() { ... defaultReport(okaySetToMsgProp, curSetting); } okaySetToMsgProp = &okaySetToMsg This way you'll be able to override okaySetToMsg(val) following the usual pattern. (This is basically the same as your workaround, but the renaming allows the standard pattern to work.) The only tricky bit is that for Dial and other subclasses, you'll have to follow the override of okaySetToMsgProp in the subclass, and override that property. For Dial, for example, you'd have override okayTurnToMsg(val) rather than okaySetToMsg(val). I'll make that change - I think that'll solve the problem for your situation, but if not reopen the bug and let me know. |
|
(0000086) Carlo (reporter) 2009-02-14 16:09 |
Even with my solution, subclasses can still override okaySetToMsg -- whether they implement it directly, or (like Dial) return another property pointer. This is because MessageResult.resolveMessageText keeps calling the property as long as calling it returns another property pointer... I just think it would be simpler that way :) |
|
(0000087) Michael Roberts (administrator) 2009-02-14 19:48 |
The problem with your original proposed change is that it could break existing code, because of the way the overrides are set up currently. If someone had an okayTurnToMsg override on Dial, that wouldn't work any more. |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2009-02-07 17:47 | Carlo | New Issue | |
| 2009-02-13 01:25 | Michael Roberts | Fixed In Version | => 3.0.18 |
| 2009-02-13 01:25 | Michael Roberts | Note Added: 0000084 | |
| 2009-02-13 01:25 | Michael Roberts | Assigned To | => Michael Roberts |
| 2009-02-13 01:25 | Michael Roberts | Status | new => resolved |
| 2009-02-13 01:25 | Michael Roberts | Resolution | open => fixed |
| 2009-02-14 16:09 | Carlo | Status | resolved => feedback |
| 2009-02-14 16:09 | Carlo | Resolution | fixed => reopened |
| 2009-02-14 16:09 | Carlo | Note Added: 0000086 | |
| 2009-02-14 19:48 | Michael Roberts | Note Added: 0000087 | |
| 2009-02-14 19:48 | Michael Roberts | Status | feedback => resolved |
| 2009-02-14 19:48 | Michael Roberts | Resolution | reopened => fixed |
| Mantis 1.1.8[^] Copyright © 2000 - 2009 Mantis Group |  |
