[doc update]: Module:init from wx_object behaviour should return wxWindow (and not …

[jurmc]

…wxObject which is not descendant of wxWindow)

I tried return sizer from Module:init (callback for wx_object module) and such initialization fails.
Current documentation is ambiguous, here https://github.com/erlang/otp/blob/master/lib/wx/src/wx_object.erl#L39 it states that wxObject can be returned from init, but ultimately start/start_link functions are documented so they return wxWindow (for example here: https://github.com/erlang/otp/blob/master/lib/wx/src/wx_object.erl#L197

Implementation definitely fail if Module:init returns something different than wxWindow, see here
https://github.com/erlang/otp/blob/master/lib/wx/src/wx_object.erl#L421

[github-actions]

CT Test Results

    2 files    17 suites   5m 37s ⏱️
155 tests 150 ✔️ 5 💤 0 ❌
171 runs  166 ✔️ 5 💤 0 ❌

Results for commit 0b64f36.

♻️ This comment has been updated with latest results.

To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass.

See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally.

Artifacts

• Complete CT logs (Download Logs)
• HTML Documentation (Download HTML Docs)
• No Windows Installer found

// Erlang/OTP Github Action Bot

[dgud]

You need to update lib/wx/doc/src/wx_object.xml
The internal edoc is currently not used.

[jurmc]

You need to update lib/wx/doc/src/wx_object.xml The internal edoc is currently not used.

Thanks, done: 97ef96b

[jurmc]

@dgud I could try to relax restrictions so maybe 'instances' of Sizers could be objects that are legal for wxObject behaviour. I'm asking if you are aware of anything in the design or implementation that renders this impossible to do or unwanted?

Of course I accept, that even if I propose something that works for me, it will be rejected for whatever reasons you'll then have.

[dgud]

I don't see the need, to me wx_object was something that could handle events (and event callbacks) and maybe add some erlang only extensions.

Adding true overloading to C++ functionality is a lot of work/hacks, that I want to avoid as far as possible.

What are you trying to do?

[dgud]

Please squash the commits and force push.

[jurmc]

Please squash the commits and force push.

Done