> On Jul 28, 2014, at 9:31 PM, Ryosuke Niwa <rn...@webkit.org> wrote:
> 
> On Mon, Jul 28, 2014 at 8:44 PM, David Farler <dfar...@apple.com 
> <mailto:dfar...@apple.com>> wrote:
> On Jul 28, 2014, at 17:10, Ryosuke Niwa <rn...@webkit.org 
> <mailto:rn...@webkit.org>> wrote:
> 
>> On Mon, Jul 28, 2014 at 12:47 PM, David Farler <dfar...@apple.com 
>> <mailto:dfar...@apple.com>> 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 
>> <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 
>> <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 
> <https://bugs.webkit.org/show_bug.cgi?id=135374> and 
> https://bugs.webkit.org/show_bug.cgi?id=135271 
> <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.

David

> 
>> The larger discussion of using Swift in larger AOT-compiled contexts but is 
>> probably going to happen in this thread anyway, so let's have it:
>> 
>> What of future use of Swift in WebKit?
>> 
>> I would really like to know why we should use Swift in WebKit at all in the 
>> current stage?
> 
> Fine, twist my arm. :) In comparison to Objective-C, I don’t think it’s a 
> stretch to think of these as major achievements:
> 
> In my opinion, the fact the language is in such a premature stage outweighs 
> any potential benefit listed here.
> 
> - R. Niwa
> 

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to