[webkit-dev] Rename PLATFORM(MAC) to PLATFORM(COCOA)?

[Benjamin Poulain]

On 1/11/14, 8:49 PM, Eric Wing wrote:
> On 1/11/14, Maciej Stachowiak <mjs at apple.com> wrote:
>>
>> On Jan 11, 2014, at 3:50 PM, Darin Adler <darin at apple.com> wrote:
>>
>>>
>>> On Jan 11, 2014, at 3:36 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>>>
>>>>
>>>> Ideally it should be USE(THE_SPECIFIC_FRAMEWORK_IN_QUESTION). I would
>>>> guess that much of PLATFORM(MAC) that is valid for both Mac and iOS
>>>> should actually be USE(FOUNDATION). PLATFORM really shouldn't be used for
>>>> things other than terminal platform names. USE(COCOA) would be an ok
>>>> stopgap if sorting down to more specific conditionals delays this cleanup
>>>> too much.
>>>
>>> Sorting down to specific conditionals will definitely delay the cleanup
>>> too much!
>>>
>>> Thinking about USE(FOUNDATION) and looking at code it’s clear that the Mac
>>> and iOS ports have a lot more in common than Foundation. I saw that
>>> looking at PLATFORM(MAC) code snippets.
>>
>> I saw that too after looking at more.
>>
>>> But as long as we’re going to have something incorrect as a first
>>> approximation, I don’t think that incorrect uses of USE(FOUNDATION) are
>>> significantly worse than incorrect uses of USE(COCOA). If long term there
>>> is not supposed to be such a thing as USE(COCOA), then I would hate to add
>>> it and then have to remove it later.
>>>
>>> It remains clear to me that a valuable and quick first step is to
>>> mechanically change PLATFORM(MAC) to BAR, and I am OK with BAR being
>>> USE(FOUNDATION), USE(COCOA), or PLATFORM(COCOA).
>>>
>>> I am sure there is a lot of easy refinement we can do immediately after.
>>> For example, we can change BAR && !PLATFORM(IOS) back to PLATFORM(MAC), if
>>> we can’t find an even better conditional. Maybe our first step can even be
>>> clever and not ever change such things to BAR, as suggested by Dan.
>>>
>>> I’d like to play the numbers game, so if our best guess is that most
>>> PLATFORM(MAC) should be USE(FOUNDATION), I would choose that for BAR.
>>
>> After thinking about it a bit - USE(COCOA) (or for that matter even
>> PLATFORM(COCOA)) might be better as a first cut. Since it's not supposed to
>> exist at all long term, it makes for an easy number to drive to zero.
>> USE(FOUNDATION) will mix both correct and incorrect uses so it will be
>> harder to drive the mistaken applications to zero.
>>
>> Regards,
>> Maciej
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
> 
> I'm new here, so sorry if I’m intruding since I don’t have much of a
> stake in this outcome, but USE(COCOA) then seems to imply to me that
> you need to also have a USE(COCOATOUCH). It so, then maybe it should
> be AppKit vs. UIKit instead for more clarity.

Here Cocoa implies both Cocoa and Cocoa Touch.

> There is another potential case where you have an Obj-C framework
> environment that is not Apple’s. I’ll cite GNUStep and Apportable as
> two cases. The former provides a Cocoa (AppKit) compatible
> implementation but tends to run on Linux or Windows. The latter
> provides a UIKit compatible implementation and tends to run on
> Android.

There is not port of WebKit for GNUStep. Consequently, it does not
impact design decisions.

> This asks the question, do you really mean Mac vs. iOS, or AppKit vs.
> UIKit, or something else?

Something else :)

The name suggested here is for all the code that is common between OS X
and iOS, but not related to the Darwin Kernel.

IMHO, COCOA is an improvement over PLATFORM(MAC).

Benjamin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 947 bytes
Desc: OpenPGP digital signature
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20140111/20a6a599/attachment.sig>