>These new Assign methods are going to get really scary really fast when code get obsured behind an = sign. Imagine debuging a code fragment like "this.that = x" when it crashes the system. Or when this.that = y causes your entire interface to dance around and change colors.
>
>I guess that its going to take sane programmers and great documentation to avoid a mess of problems!
>
>Heck, I even avoid programaticly modifing/adding form elements to avoid confusion. :)

This only seems scary now because we are not used to thinking in terms of Access and Assign methods. Once we learn to immediately recognize that accessing a method has the potential to fire code in that method's access event, it will become second nature to look there.

You could say the same thing for validation rules and update triggers, and we have grown used to them (though I have to admit, sometimes it takes me a minute to figure out I need to be debugging trigger code).

John, yes, these methods are godsends, but they don't really give us much we couldn't have before. If you wanted this functionality before you just discipline yourself to write and use get and set methods, and don't assign properties directly. A common example used for Assign methods is form.caption_assign. Well, if you created a form.setcaption() method and only use it to set the form's caption, you have just given yourself an 'assign' method.

The exceptions are a few properties that the users have direct access to, like form state. Otherwise, Access and assign are just ways to enforce discipline we could have always been enforcing on our selves.

Don't get me wrong, I can't wait to integrate them into my framework, because they have the potential to make some things a lot simpler (form.lockscreen_assign will be the top of my list). Just wanted to point out that we can create most of this functionality already.