Initialization fails

[kaloyan-raev]

1. I have VS Code 1.4.0 on Fedora 24.
2. I installed the PHP IntellSense extension as described: https://github.com/felixfbecker/vscode-php-intellisense#build-and-run-from-source
3. I opened the dev tools in VS Code from Help > Toggle Developer Tools.
4. I opened a PHP file in the editor.

The following error is printed in the Console of Dev Tools:
[Extension Host] Response handler 'initialize' failed with message: Cannot read property 'code' of null

[felixfbecker]

microsoft/vscode-languageserver-node#86

[felixfbecker]

I added a fix in felixfbecker/php-advanced-json-rpc@f9d7354 and documentSymbol works now! 🎉

[kaloyan-raev]

Yes. It works. So cool! :)

[kaloyan-raev]

BTW, I think you should apply the same pattern for JSON serialization everywhere. If an PHP object's member is null then it should not be included in the JSON object at all.

I checked the behavior of the Gson library (the most popular for JSON serialization/deserialization in Java) and it does exactly this.

[felixfbecker]

@kaloyan-raev Yes, that would be ideal, but not possible in PHP. You cannot find out at serialization time if a property was set to null explicitely or if it was simply not set, because in PHP a property is by default null if it has not been set. It works in this specific case because the spec says only error or result should ever be defined, never both, but it won't work for all the structures in the protocol where null is actually an accepted value. And it would be a huge amount of work to add the JsonSerializable interface everywhere. It would be much nicer if VS Code would just treat undefined and null the same.

I implemented the fix because I wanted advanced-json-rpc to be JSON RPC spec compatible, but for the VS Code language server protocol, we might actually have some influence on how they treat different values, and this makes it easier for developers.

[kaloyan-raev]

It is absolutely the same in Java (I am Java developer with some PHP knowledge). This is why I checked how the Gson library handles it.

What about if here: https://github.com/felixfbecker/php-advanced-json-rpc/blob/master/lib/Message.php#L44

instead of

return json_encode($this);

you have

return json_encode(array_filter((array) $obj));

Wouldn't be that a universal solution?

[felixfbecker]

No, because the spec for example says that the id in a response MUST be null if there was a parse error parsing the request and the id is unknown. It MUST be defined though, because a message without an id is considered a notification.

If we did it like this in all protocol structures, there would be no way to serialize actual null properties, that have been explicitly set to null.

Side note: you cannot cast an object directly to an array, it will include private properties. You have to do get_object_vars().

[kaloyan-raev]

OK. You are right.

[felixfbecker]

I don't like this fact about PHP either. It sucks for ORMs, you have no way to see if a column is NULL in the DB or it simply is "unknown" because wasn't eager-loaded / set after construction.