<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Sounds good, but the method "apply" sticks around, right? That, I think, is and will be the more typical way of controlling a state.</div><br><div><div>On May 14, 2008, at 4:54 PM, Henry Minsky wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">I endorse this proposal.<br><br><br><br><br><div class="gmail_quote">On Wed, May 14, 2008 at 7:23 PM, P T Withington <<a href="mailto:ptw@pobox.com">ptw@pobox.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> We need to clean up the API for states. Right now states have both an attribute _and_ a method named `apply`. This just makes no sense. It is implemented by a horrendous kludge that we will not be able to carry forward into Javascript 2 runtimes. Here's my proposal:<br> <br> 1) Deprecate `apply` the attribute. Replace it with `applied`, which is a read/write attribute whose value reflects whether or not the state is currently applied. (There is currently a property `isapplied` that is read-only that tells the state of a state, but this name is inconsistent with our name conventions. As a part of this proposal, deprecate `isapplied` and replace it with `applied`.<br> <br> The `apply` method (and it's counterpart `remove`) remain, but the preferred method for controlling a state is to constrain the `applied` property.<br> <br> We can add to the 4.x upgrade script a template that looks for `apply` in the open tag of a state and replaces it with `applied`.<br> <br> Comments?<br> </blockquote></div><br><br clear="all"><br>-- <br>Henry Minsky<br>Software Architect<br><a href="mailto:hminsky@laszlosystems.com">hminsky@laszlosystems.com</a><br><br></blockquote></div><br></body></html>