On Wed, 2 Mar 2016 11:01:12 -0800 Bill Spitzak <[email protected]> wrote:
> On Wed, Mar 2, 2016 at 4:25 AM, Pekka Paalanen <[email protected]> wrote: > > > > > > bar_obj = wl_bar_new(); > > > wl_proxy_set_queue((wl_proxy *)bar_obj, queue); > > > wl_bar_add_listener(bar_obj, ...); > > > /* whatever else to init bar_obj */ > > > wl_bar_create(bar_obj, foo_obj, ...); > > > > > > Hopefully the wl_bar_create function will appear in the documentation > > where > > > the programmer expects, in the same page as wl_bar_destroy and all the > > > other wl_bar_xyz methods. > > > > I think you have forgot the fact, that objects in the protocol sense > > cannot be created out of thin air. They are always created by a request > > on an object of a *different* type. Therefore the name must be > > wl_foo_create_bar() for wl_foo.create_bar request, not wl_bar_create() > > which would mean a wl_bar.create request. Also the "_bar" in > > "create_bar" is already encoded in the XML spec, so you cannot just > > mutilate it as you want. > > > > It's not creating it out of thin air. What I have done is rename > wl_foo_create_barEX() to wl_bar_create() You can add to the name, but you cannot really remove anything from the parts of the name that come from the XML, because it will be hard to guess what to remove. > and swapped the arguments around > so that the (blank) bar proxy is the first argument. The implementation is > unchanged and sends a message to foo. A new version of marshal that can > undo the argument rearrangement is needed however. > > The purpose is to put the "constructor" into the "namespace" (in this case > function prefix) that most programmers expect. In every language I am aware > of, the constructors are part of the object being constructed, not part of > an object needed to construct it. Your namespacing is incorrect. It is not a method on class wl_bar, it is a method on object of type wl_foo which just happens to create a new object of type wl_bar. For example, what would you do with wl_display.sync request which creates a wl_callback object? It makes absolutely no sense to call wl_display.sync as wl_callback_create(). > wl_foo_create_bar would still exist for back compatibility. Another nice > thing about this idea is that it avoids the need for "EX" to avoid > colliding with this function. > > > This is not a manually implemented C function you can just arbitrarily > > decide how to lay out, it must be generated from the XML description. > > > > I believe this can be generated by wayland_scanner as it is a different > transformation of any function that takes a newid. Except where you remove parts of a name coming from the XML. > It may make sense to add a new thing to the xml to declare this inside ba. > This would allow the comments in the xml file to be in the correct place, > and make it easier to generate the code and documentation output in the > correct order. This command could either require a matching method on foo, > or automatically generate it. It is not impossible, just very awkward, to have several different factory interfaces creating objects of a certain type. The most notable examples are wl_buffer and wl_callback. The documentation issue is unrelated, and it is solvable by a document generator already, see e.g.: https://people.collabora.com/~jonny/protocol/wl_buffer.html listing the (known) interfaces that reference the type. It would be easy to split that list into factories and mere references. The catch is that the generator needs to have all XML files available at the time to gather the information. The link comes from https://bugs.freedesktop.org/show_bug.cgi?id=83431 Thanks, pq
pgpWc3Aqg5Dq0.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
