The same applies for Java as well. Java’s reference types don’t get passed by reference. Instead, the variables are effectively pointers, and the pointers get passed by value. It’s a subtle distinction but an important one when you’re talking about programming language design.
Barbara Liskov (for the CLU language) termed this call by sharing, where the callee gets references to the arguments but can’t change what they refer to. A nice thing is that you can understand primitives (that might be passed by value as an optimisation) in the same way, as long as you lack reference equality. Since they’re immutable you can’t change them and discover that they aren’t actually shared!
Nowadays most people just understand it as ‘references passed by value’, which is less fun. ☺️
The term call by sharing still reveals a fundamentally mechanistic conception of argument passing. A better way to think about it is to make a distinction must be made between values, which exist in the semantics of a programming language (which is a timeless mathematical object, thus the question of whether it’s mutable doesn’t even make sense), and representations, which exist in computer memory (which obviously exists in time and might mutate). Now things become clearer: there is always a single number 42 and a single string “Hello, world!”, but they may be represented arbitrarily many times in computer memory.
I’ve been hacking together a small and mostly LDoc-compatible documentation generator for distribution with luakit, so that up-to-date docs can be installed with the main program. Shortcoming: type inference isn’t as nice. Benefit: it’s very easy to tweak the documentation generation and include project-specific information, e.g. auto-generate nice-looking keybinding descriptions.
The idea of stealthy ad blocking is nice, but I think it will be limited in practice. It will always be possible to draw opaque rectangles over ads, but anything further, such as reclaiming the space used by ads, is fairly easy to detect with JS. Since stealthy ad blocking merely obscures the ad, it also does not save bandwidth, prevent user tracking, save CPU usage, or protect against malware; all commonly cited reasons for blocking ads.
I guess what happens is that an empty-profile container-separated (and not root inside the container, of course) browser instance will get spun up for just enough to load the page, scroll through it and load all the scroll-loaded content, then pass the now-static content to a sanitizer which can remove everything that looks like an ad.
Tracker handling is a complicated story if websites start checking the responses for more than presence and freshness, until that you can just load them with randomized parameters and random referrer.
On the other hand, a single large enough click-spoofing false-flag-operation conflict can redraw the web landscape faster than throwaway containers come to browsing…
This is great; I really liked Luakit when I used it previously before finding out about the massive security problems. I’m glad to see it updated to the Webkit 2 API.
However, I think the documentation here glosses over the fact that there are still serious practical security problems with this library even after switching to the new API: https://blogs.gnome.org/mcatanzaro/2017/02/08/an-update-on-webkit-security-updates/
Thanks for the feedback! I’ve added a short summary of that link at the top of the download section.
Glad to see it. I would love to try out LuaKit again once Debian fixes their Webkit packages.