> On Jul 28, 2014, at 22:42, Ryosuke Niwa <[email protected]> wrote:
>
>> On Mon, Jul 28, 2014 at 10:30 PM, David Farler <[email protected]> wrote:
>>
>>> On Jul 28, 2014, at 9:31 PM, Ryosuke Niwa <[email protected]> wrote:
>>>
>>> On Mon, Jul 28, 2014 at 8:44 PM, David Farler <[email protected]> wrote:
>>>>> On Jul 28, 2014, at 17:10, Ryosuke Niwa <[email protected]> wrote:
>>>>>
>>>>>> On Mon, Jul 28, 2014 at 12:47 PM, David Farler <[email protected]> wrote:
>>>>>> Hello all,
>>>>>>
>>>>>> I have the following bug to help build out support for layout tests in
>>>>>> the iOS Simulator.
>>>>>>
>>>>>> iOS Simulator LayoutTestRelay
>>>>>> https://bugs.webkit.org/show_bug.cgi?id=135269
>>>>>>
>>>>>> I'd like to include this as a new tool written in Swift.
>>>>>>
>>>>>> Why I think it's fine in this case:
>>>>>> - This tool is specific to the iOS and OS X platforms
>>>>>> - Swift is a fully supported, albeit new, language starting in Xcode 6.
>>>>>> - Swift is probably the best way to get Objective-C bridging "for free"
>>>>>> in the long term
>>>>>> - Swift supports script-like "immediate mode" with good JIT-compiled
>>>>>> performance
>>>>>> - The tool's size and scope is sufficiently small with no complex or
>>>>>> WebKit-specific dependencies
>>>>>
>>>>> There is a precedence of WebKit rejecting the use of new programming
>>>>> languages in the past:
>>>>> https://lists.webkit.org/pipermail/webkit-dev/2011-December/018837.html
>>>>
>>>> Precedence drives opinions of law, for which reinterpretations are
>>>> considered to be an unfortunate correction. I don’t think it should be
>>>> invoked to hamper creativity or reject something “new”. Still, the main
>>>> difference to that case is that Swift is not an unsupported third-party
>>>> language, it won’t require installation of new software, and it’s not for
>>>> cross-platform automation.
>>>
>>> Swift is an unsupported third-party language for people who don't work on
>>> Mac or iOS ports.
>>>
>>>> For this project, I think it’s a valid exploration for code that would
>>>> already have to use platform-specific Objective-C. Of course, I wouldn’t
>>>> presume to argue that all of OS X and iOS WebKit code should move to Swift
>>>> at this point. However, I reject thinking that leads one to only consider
>>>> a new possibility when the current situation is unbearable or even
>>>> painfully obvious.
>>>>
>>>>> I'm not saying that Swift is a bad language or anything but I don't want
>>>>> to start having people writing random programming languages such as
>>>>> Haskell, Scala, Go, Rust, etc... deemed hip/cool at the time to create
>>>>> new tools in WebKit.
>>>>
>>>> Of course. The main difference is that I don’t deem it hip; it’s a fully
>>>> supported, productized language that ships with Xcode and it’s only going
>>>> to grow in use on OS X and iOS. Even so, that Swift is hip and exciting
>>>> shouldn’t be ignored. Developing WebKit should be as exciting to hack as
>>>> much as it is an exemplary web framework too, as both motivations work
>>>> together to make it better.
>>>
>>> In my personal opinion, "hip and exciting" should never be a reason to do
>>> anything. However, we can agree to disagree here since this is a very
>>> subjective topic.
>>>>> It would increase the entry barrier of working on those tools even if
>>>>> they were specific to one platform.
>>>>
>>>> It is something new to learn. Is it a barrier?
>>>
>>> Yes. Every new programming language we introduce into the project
>>> introduces a new entry barrier to hack on the project. Namely, everyone
>>> who ever has to modify that code need to learn Swift in addition to
>>> Objective-C/C++, which is used to write some parts of since Mac/iOS ports.
>>>
>>> I personally hate Objective-C syntax and would prefer using something like
>>> Swift. However, that preference doesn't outweigh the overall cost of
>>> introducing a new programming language into the project of this size with
>>> so many contributors.
>>>
>>>> I don’t think so. I think it’s an opportunity. We assumed Objective-C in
>>>> the first place because it was the only way to write apps and frameworks
>>>> on OS X and iOS. Now that's no longer true and, while both languages are
>>>> supported, if someone didn’t think it was the way forward, I don’t think
>>>> it would exist in the first place since Objective-C does a pretty good job
>>>> already and it could’ve been extended incrementally. That’s my
>>>> perspective. Obviously it’s not going anywhere anytime soon but, if
>>>> Objective-C were deprecated in the future, and we suddenly decided we
>>>> needed reviewers who knew Swift, where would we look?
>>>
>>> There has been no indication that Objective-C will be deprecated anytime
>>> soon.
>>>>> e.g. what should GTK+/EFL contributors do if they wanted to modify the
>>>>> way webkitpy works and needed to make changes to your tool? Or do you
>>>>> think such a scenario is extremely unlikely?
>>>>
>>>> Given the pace of webkitpy development … :) I do think it’s unlikely.
>>>
>>> That's great to hear since the cost of using Swift is proportional to the
>>> number of people who have to maintain the tool. If you're the only who has
>>> to touch the codebase, then the cost is virtually zero given that you seem
>>> to already know about Swift.
>>>
>>>> It’s just a proxy to a simulator app's standard file descriptors which are
>>>> only accessible indirectly and I’m happy to say that it somewhat pays for
>>>> its debt by removing lots more platform-specific code than it creates
>>>> (https://bugs.webkit.org/show_bug.cgi?id=135374 and
>>>> https://bugs.webkit.org/show_bug.cgi?id=135271). It doesn’t exist to
>>>> automate but make it possible to run layout tests on the simulator with
>>>> the current tools. Essentially, it pretends to be DRT/WKTR, so it has the
>>>> same I/O behavior requirements as those tools.
>>>
>>> It doesn't seem like the benefits you point out are independent of the
>>> language choice. We can still remove ORWT even if we wrote the tool in
>>> Objective-C. However, I would point out that DumpRenderTree for Mac port
>>> is written in Objective-C++, and there is a benefit in sharing code with
>>> it. Have you looked into that? Or have you decided that there is nothing
>>> we can share between the two programs?
>>
>> I did look into it. However, CoreSimulator is an OS X framework, and
>> DRT/WKTR are built as iOS Simulator binaries. The linker will not link OS X
>> dylibs to iOS executables and vice versa – although the CPU architectures
>> the same, the platform load commands conflict and cause a fatal error at
>> link time. Even if that were possible, it would involve some kind of
>> self-hosting, self-installing voodoo. A new OS X executable target is a
>> minimum requirement, as CoreSimulator is the gatekeeper to the simulator
>> device. Additionally, a single xcodebuild invocation does not like mixing
>> targets with different SDKs. However, in the future, I would like to combine
>> the DumpRenderTree and WebKitTestRunner projects. There is plenty of code to
>> share between those two targets and they aren't cohesive at all.
>
> I didn't mean to use the same binary but rather to share the source code to
> avoid the code duplication.
>
> - R. Niwa
I see. No, it is unique code that wouldn't be useful to the dump tools.
David
_______________________________________________
webkit-dev mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-dev
