<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Nov 18, 2013, at 1:11 PM, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 18, 2013 at 1:05 PM, <a href="mailto:kledzik@apple.com">kledzik@apple.com</a> <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Beside compatibility with existing files (which we don't have yet), there is another reason for V1 vs V2: size. The NativeReferenceIvar is twice the size (8 bytes vs 4 bytes). There will be a lot of these in files. We should have both structs. When a native object file is written, the Writer should see if everything is small enough that just NativeReferenceIvarsV1 structs can be used. If not, it uses NativeReferenceIvarsV2. The Reader should always handle both.<br>
</blockquote><div><br></div><div>Then we should name NativeReferenceIvars16 and NativeReferenceIvars64 because V2 is not really a newer version of V1. </div></div></div></div>
</blockquote></div><br><div>In the file format, each struct can evolve independently. Think of “V” as “Variant" not “Version". It was not meant to imply that a larger version is “better” than a smaller.</div><div><br></div><div>If you rename the current one to NativeReferenceIvars16, what happens when we add some new concept to the atom model and need to add a field to a new variant of NativeReferenceIvars for object files that need the new concept? </div><div><br></div><div>-Nick</div></body></html>