&nbsp;mike clemow:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I&#39;m really into this idea too! &nbsp;I really don&#39;t like that I can&#39;t<br>

overwrite a class definition.<br>
</blockquote><div><br>&nbsp;</div></div>I think this is to prevent worse issues. If you&#39;d change your class&#39;s member-function return types that would lead to serious issues with other code that was already compiled using those. I think this matter is affected by many (if not all?)of the issues affecting the updating of running code.<br>
<br>I have a suspicion we may need to demand that updated functions have to stick to the same return type they were defined with. Adding stuff is probably fine but removing any class members could also lead to issues with code that depends on them.<br>
<br>I don&#39;t think it&#39;s even so clear how such things should be dealt with, interface-wise. Maybe this will be where the real advantage of the Audicles is. Perhaps a closer link between the VM and the edit buffers, for us to indicate what we want and for the VM to indicate what our limitations are.<br>
<br>It might be a different matter for public classes that currently aren&#39;t instantiated anywhere and that aren&#39;t referenced by any running code.<br><br>Yours,<br>Kas.<br>