> 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
