ColdFrame: Issues

Current issues are to be found on the Github Issues page.

Historical issues are to be found on this Sourceforge Tickets page.

Outstanding non-logged issues

These issues never made it onto any formal ticketing system.

0062 (raised 23.i.02)

It would be useful to be able to specify constants.
Pi is specially handled, in "expression" contexts (initial values, {real} ranges).

0078 (raised 18.iv.02)

ColdFrame doesn't detect the error of having non-unique abbreviations.

0174 (raised 17.vi.03)

The error of making an Association with a «type» should be detected (instead of generating bad code).

0182 (raised 9.vii.03)

Using {formalizes} on a non-class attribute gives an unhelpful error message.

0183 (raised 9.vii.03)

Using {imported} (and possibly others) on a «type» with attributes gives an unhelpful error message.

0184 (raised 9.vii.03)

«public» and «singleton» classes have a Create operation which is not meant to be called by handwritten code. Perhaps it should be renamed.

0203 (raised 16.ix.03)

When checking whether an abstract operation has been implemented, ColdFrame doesn't check that the operation profiles match (for example, that both are procedures or both functions). This can lead to compilation errors in generated code.

0240 (raised 2.iii.04)

The Event Queue operation Unset assumes it's called in an action (ie, with the Event Queue locked).

0253 (raised 19.iv.04)

In a state chart, the error of having more than one state with the same name is not detected as such (this really only happens if you name one of your states initial or final, which are the default names used for initial and final states).

0265 (raised 26.v.04)

There is no check that associations' multiplicities have been maintained.

0277 (raised 26.vii.04)

The error messages that are given if there's a relationship involving a class not in the current package (either from a non-«generate» child or from another domain altogether) aren't as helpful as they could be.

0283 (raised 11.ix.04)

The generated code won't compile if all the attributes of a «public» class are «class» attributes.
If you feel you absolutely must have «class» attributes, add a dummy instance attribute as well. But it's not obvious why you'd want to.

0285 (raised 6.xi.04)

The fact that an operation's parameter has a default value isn't considered when checking whether the operation is allowable as an action.

0292 (raised 31.i.05)

There's no way of seeing the {revision} string for a «generate»d (now «include»d) package.

0332 (raised 30.ix.05)

You can't use events-to-self from an event that's being handled synchronously.

0342/1401275 (raised 10.i.06)

ColdFrame's checks on state machines don't properly handle the case where actions are inherited; in particular, the error of having transitions (particularly completion transitions) from a state with a «final» action (ie, where the instance has been deleted) may not be detected.
26.x.07: checks now include inherited actions, but the reported problem still exists.

0362 (raised 5.ix.06)

Generated unit test support fails to compile if a «public» class has an attribute of a private type.
On the whole it's best if public classes don't have attributes at all.

0369/1964067 (raised 14.v.08)

If an instance event is declared with «instance event» but there's no corresponding transition on the state machine, the generated spec requires a handler which the body doesn't provide.