r185873 - [Objective-C migrator] replace candidate user setter/getter with

[Arthur O'Dwyer]

On Wed, Jul 10, 2013 at 11:15 AM, jahanian <fjahanian at apple.com> wrote:
>
> So, we will be dealing with situations where person who migrating with the
> implementation on-hand will migrate one way and every one else using
> the frameworks will migrate (potentially) some other way. Interesting
> scenario deserving talking off-line.

FWIW, I don't understand what it means to "migrate" code that merely
*uses* a third-party framework. Wouldn't the use be pretty much
limited to

    #import <ThirdParty/ThirdParty.h>

and then the migrator would know not to touch that external header
(any more than it would touch <Foundation/Foundation.h>), and
therefore there'd be nothing to worry about?

The workflow would be
(1) FirstParty Inc. and SecondParty Inc. both write code #importing
Version 1.0 of a header sold by ThirdParty Inc.
(2) ThirdParty Inc. uses the migrator to migrate their old interface
and implementation to ObjC 2.0, and releases the new code as Version
2.0. The 2.0 release probably includes a bunch of other API changes,
too.
(3a) FirstParty Inc. manually updates their code to #import Version
2.0 of ThirdParty's interface. Regardless of tool support, this update
is almost certainly going to be manual, not mechanical, since
ThirdParty 2.0's interface is so different from ThirdParty 1.0's. Once
this manual process is done, they may or may not choose to migrate
their own codebase to ObjC 2.0 using the migrator.
(3b) SecondParty Inc. uses the migrator to migrate their
implementation to ObjC 2.0, but does not shell out the cash to upgrade
their ThirdParty installation. They continue using ThirdParty 1.0. The
migrator doesn't interfere with their decision.

my $.02,
–Arthur