Re: [webkit-dev] Code Style: Opinion on returning void

[Ryosuke Niwa]

On Thu, Feb 21, 2019 at 9:31 AM Darin Adler  wrote:

> I tried not to weigh in on this, but my view on the materials we should
> use to build the bike shed must be shared!
>
> Generally it seems neat to be able to make the code slightly more tight
> and terse by merging the function call and the return into a single
> statement.
>
> Other than not being accustomed to it, I have noticed three small things I
> don’t like about using “return” with a call to a void-returning function.
>
> - You can’t use this idiom when you want to ignore the result of a
> function, only if the function actually returns void. Often functions are
> designed with ignorable and often ignored return values. For example, it’s
> common to call something that might fail and have a good reason to ignore
> whether it failed or not. The idiom we are discussing requires treating
> those functions differently from ones that return void. If you refactor so
> that a function now returns an ignorable return value you need to visit all
> the call sites using return and change them into the two line form.
>

Perhaps this is the key distinction we want to make. Maybe if the *intent*
is to ignore the function's return value regardless of what it may return
in the future, then we should have a separate "return". If the *intent* is
to return whatever that other function returns, then we should return void.
But having to think about the intent of code isn't a great thing for coding
style guideline.

- It works for return, but not for break. I’ve seen at least one case where
> someone filled a switch statement with return statements instead of break
> statements so they could use this more-terse form. Now if we want to add
> one line of code after that switch, we need to convert all those cases into
> multi-line statements with break.
>

This is an orthogonal point but I do prefer switch'es that return directly
over one that break's then having a separate return after the switch
statement especially if the switch statement is long.

I've gotta say I'm fascinated to learn that many people are bothered by
returning void. I guess I was never bothered by it because I see a return
statement as a thing that returns the control back to the caller, not a
thing that returns a value.

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

Re: [webkit-dev] For your consideration: Naming scheme for fooIfExists/ensureFoo

[Ryosuke Niwa]

For those who joined webkit-dev after June 2013, see
https://lists.webkit.org/pipermail/webkit-dev/2013-June/thread.html#25056

On Thu, Feb 21, 2019 at 7:54 PM Ryosuke Niwa  wrote:

> I guess we never remembered to update our style guideline back in 2013.
>
> I've uploaded a patch to do this:
> https://bugs.webkit.org/show_bug.cgi?id=194930
>
> - R. Niwa
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] For your consideration: Naming scheme for fooIfExists/ensureFoo

[Ryosuke Niwa]

I guess we never remembered to update our style guideline back in 2013.

I've uploaded a patch to do this:
https://bugs.webkit.org/show_bug.cgi?id=194930

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

[webkit-dev] WinCairo Intent to Deprecate WebKitLegacy

[Don . Olmstead]

Hi WebKittens,

Since taking over development of the WinCairo port we've made a lot of good 
progress with enabling Modern WebKit on Windows. Because of that we plan on 
beginning to remove support of WebKitLegacy on the WinCairo port and switch to 
a fully Modern WebKit implementation. This will enable us to use new web 
features such as Service Workers which are unavailable through WebKitLegacy.

In the near future we plan on moving our bots to using WebKitTestRunner for 
testing WinCairo. After that is completed we will be working on removing 
WebKitLegacy from the WinCairo build. I've made a tracking bug at 
https://bugs.webkit.org/show_bug.cgi?id=194904 for the work around this plan 
and we will update it as work continues towards this goal. If you are using 
WinCairo in your product we ask that you subscribe to that bug and engage with 
us there.

Thanks,
Sony WebKit Team
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Code Style: Opinion on returning void

[Darin Adler]

I tried not to weigh in on this, but my view on the materials we should use to 
build the bike shed must be shared!

Generally it seems neat to be able to make the code slightly more tight and 
terse by merging the function call and the return into a single statement.

Other than not being accustomed to it, I have noticed three small things I 
don’t like about using “return” with a call to a void-returning function.

- You can’t use this idiom when you want to ignore the result of a function, 
only if the function actually returns void. Often functions are designed with 
ignorable and often ignored return values. For example, it’s common to call 
something that might fail and have a good reason to ignore whether it failed or 
not. The idiom we are discussing requires treating those functions differently 
from ones that return void. If you refactor so that a function now returns an 
ignorable return value you need to visit all the call sites using return and 
change them into the two line form.

- It works for return, but not for break. I’ve seen at least one case where 
someone filled a switch statement with return statements instead of break 
statements so they could use this more-terse form. Now if we want to add one 
line of code after that switch, we need to convert all those cases into 
multi-line statements with break.

- Unless it’s mandatory, it’s a case where two programmers can make different 
style choices. If both forms are acceptable, then it introduces a little bit of 
disorder into our code.

One thing I like about it is that since “pass along the return value from this 
inner function to this outer function” can be written this way, the code can 
then survive refactorings where both the inner and outer functions might gain 
or lose the return value.

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

[webkit-dev] Turning on/off web preferences during iOS development

[Frédéric Wang]

Hi everybody,

I was wondering if there is an easy way to enable or disable a web
preference on iOS (simulator). Some of them are in the "experimental
features" menu but (at least with the public SDK) it has not always
worked well during development [1]. Moreover, most of the preferences
are now "internal features".

For the mac port, one can use the Experimental/Internal features menu in
minibrowser. For other ports, one can just modify the default value in
WebPreferences.yaml and rebuild, but that's a bit against the idea of a
runtime setting.

Any idea?

Thanks,

Frédéric

[1] https://bugs.webkit.org/show_bug.cgi?id=182485

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

Re: [webkit-dev] Moving to Git

[Simon Fraser]

> On Feb 21, 2019, at 12:18 AM, Bug Tracker 
>  wrote:
> 
> Thank you all very much for your help! I really appreciate it. :-)
> 
> P.S.: I decided to start learning git-svn.

https://trac.webkit.org/wiki/UsingGitWithWebKit 
 has the information you need.

Simon

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

Re: [webkit-dev] Moving to Git

[Bug Tracker]

Thank you all very much for your help! I really appreciate it. :-)

P.S.: I decided to start learning git-svn.



‐‐‐ Original Message ‐‐‐
On Wednesday, February 20, 2019 11:48 PM, Adrian Perez de Castro 
 wrote:

> On Wed, 20 Feb 2019 22:30:22 +0300, Konstantin Tokarev annu...@yandex.ru 
> wrote:
>
> > 20.02.2019, 22:27, "Bug Tracker" bug.tracking.acco...@protonmail.com:
> >
> > > Sorry, for the anonymous email. I opted for it because the list archives 
> > > are public and concluded that it's not that useful to reveal my identity 
> > > for the purposes of this question.
> > > In short, however, I am a graduate student interested in using WebKit for 
> > > an academic project and thought that I should ask first about the 
> > > progress on Git migration, since it would be far easier for me to work 
> > > with WebKit then.
> >
> > You can use public Git mirror:
> > https://github.com/WebKit/webkit
>
> You can even do upstream WebKit development using exclusively Git, even
> without needing to use the GitHub mirror, see:
>
> https://trac.webkit.org/wiki/UsingGitWithWebKit#Checkout
>
> Even for things which would normally require Subversion, “git svn” can be
> used 99.9% of the time. For the usual “pull latest code from master, make
> a branch, prepare a patch, upload patch to Bugzilla for landing” Subversion
> is not needed at all. Just make sure you have 20 to 30 GiB of space for the
> Git checkout and building WebKit.
>
> For other more specialized workflows, like checking out release branches and
> version tags you will need some “git svn” usage; but IMO that is still nicer
> than having to use Subversion.
>
> I hope this helps!
>
> -Adrián


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