Some other advantages just came to mind: - easier code sharing between API clients. Midori and Ephy could share a common NotificationPresenter/StatusWatcher/... for example - easier to inject stubs for unit testing - let the compiler do the typechecking for us by avoid gpointer casts - ...
Obviouslt signals have there use for unscheduled/unexpected events. But in most case, method calls is a good way to pass control flow to user code ;) Le vendredi 16 septembre 2011 à 09:29 +0200, Alexandre Mazari a écrit : > Hi Carlos, > > Great that with the transition to wk2, we have the occasion to rethink a > bit the API. > > As stated in https://bugs.webkit.org/show_bug.cgi?id=61140#c22 , we > might use this occasion to rethink our current (over) usage of signals > and properties. > WebView API currently suffers, IMHO, from having so much unrelated data > and codepath delegation. This do not enforce a clean OO model on both > webkit's and API user's code. Both of them going mostly procedural, have > huge LoC count and fiddle with data sharing. Also we currently flatten > the WebCore object model by putting so much in one class. > > Also, most of those signals will have only one listener in the client > code, rendering signals multiplexing/marshalling useless. > > We should enforce the user code to be smaller independent testable parts > instead. > > Related delegators (currently signals) could go into interface instead. > Implementations of those would then be provided and used by the webview. > Don't call us, we call you... > So for example we could have the following instead of the current > signals: > > interface WebKitNotificationPresenter { > def authRequested (...); > def checkAuth (...); > def showNotification (...); > def cancleNotification (...); > } > and WebKitWebView::setNotificationPresenter > (WebKitNotificationPresenter) > > The API user would then provide an implementation of the interface. > > Advantages: > - The code and data related to the topic (here notifications) are > isolated > - the class can be tested separately > - the code is more readable, so are stacktraces > - no more intermediate struct types to pass as user_data to callbacks, > everything is in the class > - limoit the scope of sides effects > - the lifecycle of such a delegator class is easier to handle than > multiple data structures. > > Cons: > - GObject interface implementation is cumbersome, but this is mitigated > by bindings > > I have the feeling signals have bee overused in webkit (and elsewhere in > the platform) for this exact reason. C/GObject low-level complexity > often divert dev from nice oo design for convenience. But that make > testing and maintaining harder, I guess. OT: Vala looks like an > interesting solution to alleviate that. > > > _______________________________________________ > > webkit-gtk mailing list > > [email protected] > > http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk > > > _______________________________________________ > webkit-gtk mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk _______________________________________________ webkit-gtk mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
