Re: [webkit-dev] Swift in WebKit

[Gavin Barraclough]

On Jul 28, 2014, at 12:47 PM, David Farler  wrote:

> - Swift is a fully supported, albeit new, language starting in Xcode 6.

I think you missed a word off the end of this sentence – Swift support is 
available in Xcode 6 beta. ;-)

Too soon.
G.


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

Re: [webkit-dev] Swift in WebKit

[David Farler]

> On Jul 28, 2014, at 22:42, Ryosuke Niwa  wrote:
> 
>> On Mon, Jul 28, 2014 at 10:30 PM, David Farler  wrote:
>> 
>>> On Jul 28, 2014, at 9:31 PM, Ryosuke Niwa  wrote:
>>> 
>>> On Mon, Jul 28, 2014 at 8:44 PM, David Farler  wrote:
> On Jul 28, 2014, at 17:10, Ryosuke Niwa  wrote:
> 
>> On Mon, Jul 28, 2014 at 12:47 PM, David Farler  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.
>>> 
>>

Re: [webkit-dev] Swift in WebKit

[Ryosuke Niwa]

On Mon, Jul 28, 2014 at 10:30 PM, David Farler  wrote:

>
> On Jul 28, 2014, at 9:31 PM, Ryosuke Niwa  wrote:
>
> On Mon, Jul 28, 2014 at 8:44 PM, David Farler  wrote:
>
>> On Jul 28, 2014, at 17:10, Ryosuke Niwa  wrote:
>>
>> On Mon, Jul 28, 2014 at 12:47 PM, David Farler  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 sta

Re: [webkit-dev] Swift in WebKit

[David Farler]

> On Jul 28, 2014, at 9:31 PM, Ryosuke Niwa  wrote:
> 
> On Mon, Jul 28, 2014 at 8:44 PM, David Farler  > wrote:
> On Jul 28, 2014, at 17:10, Ryosuke Niwa  > wrote:
> 
>> On Mon, Jul 28, 2014 at 12:47 PM, David Farler > > 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

Re: [webkit-dev] Swift in WebKit

[Ryosuke Niwa]

On Mon, Jul 28, 2014 at 8:44 PM, David Farler  wrote:

> On Jul 28, 2014, at 17:10, Ryosuke Niwa  wrote:
>
> On Mon, Jul 28, 2014 at 12:47 PM, David Farler  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://b

Re: [webkit-dev] Swift in WebKit

[David Farler]

On Jul 28, 2014, at 17:10, Ryosuke Niwa mailto:rn...@webkit.org>> wrote:

> On Mon, Jul 28, 2014 at 12:47 PM, David Farler  > 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.

> In particular see Maciej's response in 
> https://lists.webkit.org/pipermail/webkit-dev/2011-December/018865.html 
> .

From the second e-mail:

"In conclusion, I think we should be very hesitant to introduce new languages 
for tools unless there are massive benefits that cannot be achieved with any of 
the languages that the WebKit project already uses.”

I myself am hesitant, hence the e-mail, but I think there is more to the 
picture here regarding the two languages which I outline below.

For everyday automation tasks, I agree that we should continue to converge on 
Python because of its coverage across platforms, one-way-to-do-it-ness, strong 
style guidelines, large standard library, popularity, easy to learn, etc. It’s 
one of my goals to do just that and create a strong, unified, hackable, 
well-documented tools platform. I wouldn't advocate that automation be written 
in Swift.

> I understand that its freshness and continual evolution means that we won't 
> reviewer support relative to our C family languages. I would argue that it 
> will be difficult to subjectively tell when the time is "right", that a good 
> way to solve that is to start using the language itself, and take an 
> incremental approach to crafting the Swift story in WebKit. Using it for some 
> simple tools is a good place to start.
> 
> Could you clarify what the advantage of using Swift is?  Personally, I'm not 
> interested in learning a yet another platform-specific language to hack on 
> WebKit.

Sure. There is a book, website, blog and conference touting the advantages of 
Swift. :) I’m not going to fall into the trap of trying assume responsibility 
for articulating what has already been said there because I’ll surely not do as 
good of a job, but I’ll provide some enticing bullets below. If you took the 
time to learn and use it, I think you would appreciate the advantages and 
disadvantages more and would be excited for its future. I am.

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.

> 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? 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 

Re: [webkit-dev] Swift in WebKit

[Ryosuke Niwa]

On Mon, Jul 28, 2014 at 12:47 PM, David Farler  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

In particular see Maciej's response in
https://lists.webkit.org/pipermail/webkit-dev/2011-December/018865.html.

I understand that its freshness and continual evolution means that we won't
> reviewer support relative to our C family languages. I would argue that it
> will be difficult to subjectively tell when the time is "right", that a
> good way to solve that is to start using the language itself, and take an
> incremental approach to crafting the Swift story in WebKit. Using it for
> some simple tools is a good place to start.
>

Could you clarify what the advantage of using Swift is?  Personally, I'm
not interested in learning a yet another platform-specific language to hack
on WebKit.

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.

It would increase the entry barrier of working on those tools even if they
were specific to one platform.

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?

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?

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Swift in WebKit

[Sam Weinig]

On Jul 28, 2014, at 4:38 PM, Geoffrey Garen  wrote:

>>> (2) The language and implementation are still changing in breaking ways.
>> 
>> Yep, I concede to this. My only question in response is whether it's 
>> valuable to observe those changes in a project like this or even to use a 
>> project like this to investigate other points of discussion, like:
>> 
>> - Is there one Swift coding style? If not, what's ours?
>> - What do we need to implement in spite of, or for lack of, a standard 
>> library feature?
>> 
>> Or, just save all that for a rainy day, I suppose.
> 
> Interesting. I think it might be valuable to do these things in a limited 
> project, if we can minimize the downside of breaking changes.
> 
> Geoff

I’d also be okay with allowing Swift, in this limited fashion, as an experiment.

- Sam

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

Re: [webkit-dev] Swift in WebKit

[Geoffrey Garen]

>> (2) The language and implementation are still changing in breaking ways.
> 
> Yep, I concede to this. My only question in response is whether it's valuable 
> to observe those changes in a project like this or even to use a project like 
> this to investigate other points of discussion, like:
> 
> - Is there one Swift coding style? If not, what's ours?
> - What do we need to implement in spite of, or for lack of, a standard 
> library feature?
> 
> Or, just save all that for a rainy day, I suppose.

Interesting. I think it might be valuable to do these things in a limited 
project, if we can minimize the downside of breaking changes.

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

Re: [webkit-dev] Swift in WebKit

[David Farler]

> On Jul 28, 2014, at 2:57 PM, Geoffrey Garen  wrote:
> 
> Two concerns that came up today:
> 
> (1) A binary built with Swift today can only run if the client individual has 
> the same version of Xcode installed. (Is this true?)

Not sure if it's true (I haven't hit this) but I wouldn't be surprised if there 
are ABI-breaking changes across beta releases, especially regarding the 
underlying bridging to the Objective-C runtime. I don't know how often that 
will happen long term.

I should mention though that LayoutTestRelay will inherently have a dependency 
on CoreSimulator.framework inside the Xcode.app bundle, so if LTR is built 
against a particular location, it will have to either be rebuilt or have its 
rpath adjusted if using the common /Applications/Xcode.app location, regardless 
of the language.

> (2) The language and implementation are still changing in breaking ways.

Yep, I concede to this. My only question in response is whether it's valuable 
to observe those changes in a project like this or even to use a project like 
this to investigate other points of discussion, like:

- Is there one Swift coding style? If not, what's ours?
- What do we need to implement in spite of, or for lack of, a standard library 
feature?

Or, just save all that for a rainy day, I suppose.

David

> 
> Geoff
> 
>> On Jul 28, 2014, at 2:21 PM, Sam Weinig > > wrote:
>> 
>> Hi David,
>> 
>> I think it is a bit too early to start using Swift in WebKit, especially 
>> since the language is still evolving.  Eventually, I think we should start 
>> using it, but I’d like for it to settle a bit before we do.
>> 
>> - Sam
>> 
>> 
>> On Jul 28, 2014, at 12:47 PM, David Farler > > 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
>>> 
>>> I understand that its freshness and continual evolution means that we won't 
>>> reviewer support relative to our C family languages. I would argue that it 
>>> will be difficult to subjectively tell when the time is "right", that a 
>>> good way to solve that is to start using the language itself, and take an 
>>> incremental approach to crafting the Swift story in WebKit. Using it for 
>>> some simple tools is a good place to start.
>>> 
>>> 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?
>>> 
>>> Regards,
>>> David Farler
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org 
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org 
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 

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

Re: [webkit-dev] Swift in WebKit

[Geoffrey Garen]

Two concerns that came up today:

(1) A binary built with Swift today can only run if the client individual has 
the same version of Xcode installed. (Is this true?)

(2) The language and implementation are still changing in breaking ways.

Geoff

> On Jul 28, 2014, at 2:21 PM, Sam Weinig  wrote:
> 
> Hi David,
> 
> I think it is a bit too early to start using Swift in WebKit, especially 
> since the language is still evolving.  Eventually, I think we should start 
> using it, but I’d like for it to settle a bit before we do.
> 
> - Sam
> 
> 
> On Jul 28, 2014, at 12:47 PM, David Farler  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
>> 
>> I understand that its freshness and continual evolution means that we won't 
>> reviewer support relative to our C family languages. I would argue that it 
>> will be difficult to subjectively tell when the time is "right", that a good 
>> way to solve that is to start using the language itself, and take an 
>> incremental approach to crafting the Swift story in WebKit. Using it for 
>> some simple tools is a good place to start.
>> 
>> 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?
>> 
>> Regards,
>> David Farler
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Swift in WebKit

[Sam Weinig]

Hi David,

I think it is a bit too early to start using Swift in WebKit, especially since 
the language is still evolving.  Eventually, I think we should start using it, 
but I’d like for it to settle a bit before we do.

- Sam


On Jul 28, 2014, at 12:47 PM, David Farler  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
> 
> I understand that its freshness and continual evolution means that we won't 
> reviewer support relative to our C family languages. I would argue that it 
> will be difficult to subjectively tell when the time is "right", that a good 
> way to solve that is to start using the language itself, and take an 
> incremental approach to crafting the Swift story in WebKit. Using it for some 
> simple tools is a good place to start.
> 
> 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?
> 
> Regards,
> David Farler
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[webkit-dev] Swift in WebKit

[David Farler]

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

I understand that its freshness and continual evolution means that we won't 
reviewer support relative to our C family languages. I would argue that it will 
be difficult to subjectively tell when the time is "right", that a good way to 
solve that is to start using the language itself, and take an incremental 
approach to crafting the Swift story in WebKit. Using it for some simple tools 
is a good place to start.

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?

Regards,
David Farler
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Any old-run-webkit-tests clients left?

[Dirk Pranke]

iOS was the only one I was aware of that was left.

-- Dirk


On Mon, Jul 28, 2014 at 12:25 PM, David Farler  wrote:

> Hi,
>
> Are there any ports or users of old-run-webkit-tests left besides the iOS
> Simulator? I'm on the verge of completing iOS Simulator support for
> webkitpy and run-webkit-tests so, once the new port is stable, I'd like to
> consider removing this code.
>
> David
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Any old-run-webkit-tests clients left?

[David Farler]

Hi,

Are there any ports or users of old-run-webkit-tests left besides the iOS 
Simulator? I'm on the verge of completing iOS Simulator support for webkitpy 
and run-webkit-tests so, once the new port is stable, I'd like to consider 
removing this code.

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