Bug 12381 - Introducing PageClient
Summary: Introducing PageClient
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: Platform (show other bugs)
Version: 420+
Hardware: PC OS X 10.4
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-23 06:15 PST by Zack Rusin
Modified: 2013-05-02 11:59 PDT (History)
2 users (show)

See Also:


Attachments
PageClient (30.67 KB, patch)
2007-01-23 06:16 PST, Zack Rusin
mjs: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Zack Rusin 2007-01-23 06:15:30 PST
Lack of PageClient causes a few woes all over the place. Esthetically speaking, passing of all the client objects to the PageClient is really awkward plus it makes memory managment very unintuitive (users create clients and pass them to the Page and Page steals them and takes over owenership).

The attached patch introduces PageClient which acts as a manager/factory for other client objects, and also makes it a lot clearer that Page is owning them.
Comment 1 Zack Rusin 2007-01-23 06:16:14 PST
Created attachment 12625 [details]
PageClient
Comment 2 Sam Weinig 2007-01-23 09:11:39 PST
You probably want to update change the copyright information to say 2007. 
Comment 3 Geoffrey Garen 2007-01-24 18:52:46 PST
I don't think this patch is right.

First, a Page does *not* own its clients. One WebKit design might delete the client when the page was done with it, but another might reuse a single client for all pages, while another still might have a client that needed to outlive its page. The whole notion of a Page owning a client contradicts the name "client."

Second, a "client client" is an extra level of indirection which, to me, makes things more awkward, not less. In the current design, whoever constructs a Page needs to know how to construct the Page's clients. In the "client client" design, whoever constructed a Page would need to know to construct a mediating object that would know how to construct the Page's clients at some arbitrary future date.
Comment 4 Maciej Stachowiak 2007-01-24 19:24:15 PST
Comment on attachment 12625 [details]
PageClient

I have the same basic thoughts about this as Geoff. I think the extra level of indirection just makes things more complicated.
Comment 5 Zack Rusin 2007-01-24 23:35:39 PST
First, current behavior of clients staying beyond the lifecycle of the Page is in no way affected by this patch. 

Second, the notion of having one codepath that knows how to construct clients is cleaner than having the same code spread in the master object that happens to be creating the Page. 

The patch was meant to cleanup the Page constructor which is only going to get worse and it does that. If you don't like it, that's fine I won't be pushing it, but at least lets reject it because we don't like it not because of non-existant problems.
Comment 6 Anders Carlsson 2013-05-02 11:59:08 PDT
This bug has been open for 6 years and is not going to be fixed. Let's just close it.