On Mon, Jul 28, 2014 at 10:30 PM, David Farler <dfar...@apple.com> wrote:
> > 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> wrote: > >> On Jul 28, 2014, at 17:10, Ryosuke Niwa <rn...@webkit.org> wrote: >> >> On Mon, Jul 28, 2014 at 12:47 PM, David Farler <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 >>> >>> 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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev