Note that a class is not resolved this was. …::class is not a function
call. It's more like a named string constant. Technically still a
string. The advantage is that IDEs and tools like linters can much easier
understand that these strings refer to a class, and list them in usage
reports, renames, and such.
Change-Id: I5225543dbb837685a1840837cb2772dd576cca38
* deprecate and fix pickHost. It was broken and never used.
* simplify inputTypeSelection
* remove superfluous is_array check for the result of explode
Change-Id: I392f22f074facfe30b97d53a3002f464a471b67e
In T74240 support for LaTeX based rendering of the <math/>-tags was
removed. This change eliminates the unused code from the repository.
Bug: T195871
Change-Id: Ic57d83fa49f090b574ce8b82fd2ebc84a5350318
* Use the exactly same routines to deliver png images that are used in
mathml mode.
* Change the output to use mathoids png image rather than the mathml
and svg output.
* Locally tested on Firefox and Chrome: Depending on the mode either
the SVG or the PNG path is used.
Bug: T74240
Change-Id: I4b1cac92eb9a02190f316faab6621940951603d5
The motivation for this patch is to make the code less complex, better
readable, and less brittle.
Example:
public function onExampleHook( Parser &$parser, array &$result ) {
/* This is the hook handler */
}
In this example the $result array is meant to be manipulated by the
hook handler. Changes should become visible to the caller. Since PHP
passes arrays by value, the & is needed to make this possible.
But the & is misplaced in pretty much all cases where the parameter is
an object. The only reason we still see these & in many hook handlers
is historical: PHP 4 passed objects by value, which potentially caused
expensive cloning. This was prevented with the &.
Since PHP 5 objects are passed by reference. However, this did not
made the & entirely meaningless. Keeping the & means callees are
allowed to replace passed objects with new ones. The & makes it look
like a function might intentionally replace a passed object, which is
unintended and actually scary in cases like the Parser. Luckily all
Hooks::run I have seen so far ignore unintended out-values. So even if
a hook handler tries to do something bad like replacing the Parser
with a different one, this would not have an effect.
Removing the & does not remove the possibility to manipulate the
object. Changes done to public properties are still visible to the
caller.
Unfortunately these & cannot be removed from the callers as long as
there is a single callee expecting a reference. This patch reduces the
number of such problematic callees.
Change-Id: I21d53c989ea487607dc69e6b3365c023ef6729f5
Without this change it would no longer load in safe mode (T185303)
because the module would be missing.
I think this has been copy-pasted from VisualEditor, see commit
I6d097ccbf1dc2462843219adcf96bf8313e30289 there for explanation.
Bug: T185303
Change-Id: I6644a361d1450c394a7f82dc3dad97515982846d
Without this change it would no longer load in safe mode (T185303)
because the module would be missing.
I think this has been copy-pasted from VisualEditor, see commit
I6d097ccbf1dc2462843219adcf96bf8313e30289 there for explanation.
Bug: T185303
Change-Id: Ieed46488c94c5809e9f17f667c6926a21ffe838b
