Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
I should note, I don't think this is possible for JS objects, it certainly would not be possible for arbitrary WebCore/WebKit objects. I noticed the patch was re-landed, which surprises me since we are still discussing it, why was this? -Sam On Thu, Jun 3, 2010 at 5:02 PM, Timothy Hatcher wrote: > Even if that wont prevent Sam's proposed information leak, I think this > would be good to do. That way developers only see what they are affecting. > Otherwise a developer might chase a red herring if they have Gmail or > something open in the background and keep seeing spikes of memory are not > caused by their page. > > On Jun 2, 2010, at 2:45 PM, Mikhail Naganov wrote: > > > Used memory count can be restricted to include only objects reachable > > from the caller execution context. In this case, an app could only see > > the amount of memory consumed by itself, not by the whole engine. > > — Timothy Hatcher > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making changes to our copy of the W3C CSS1 test suite
On Jun 3, 2010, at 2:30 PM, Ojan Vafai wrote: > On Wed, Jun 2, 2010 at 6:20 PM, Darin Adler wrote: >1) There’s one directory with a pristine copy of the W3C test suite, with > no WebKit changes. >2) If there are some tests that need to be fixed, fixed copies of those > individual tests would go into another directory. > > So we would know that if css3-fixed-up/foo.html exists to skip > css3-pristine/foo.html? Not necessarily. We can skip the pristine one if we have to, but generally speaking I think we should run the pristine one and the fixed up one too. >3) The broken tests can be run as-is, and we can land expected results to > reflect what the broken tests do. > > Perhaps I would think differently about some aspect of this if we had > introduced the “test expectations” concept for platforms other than Chromium. > > It's a tradeoff. On the one hand, the test expectations approach lets you > have a list of failing tests that you drive to 0. On the other hand, checking > in failing expectations lets you know if you ever unintentionally change the > the type of failure (e.g. it was failing for one reason and is now failing > for a different reason due to your patch). If we intend to have a concerted, > short-term effort to drive the failing tests to 0, then an expectations > approach seems better. Maybe we should come up with a system that does both. > There should be some set of tests that are faster to run that omits the > slower thorough tests. This was the original goal of “fast” but we have put > tests outside “fast” more or less at random. Why are “editing” tests outside > “fast”? Just the whim of the person who added them. Same comment on > directories like “accessibility”. > > I don't like the concept of putting fast tests in a separate top-level > directory. Neither do I. I said this was the original concept, but I meant that we should accomplish this a new way now. > If we want a way to run just the fast tests, we should just come up with a > way of annotating tests as slow. Another option is that we could have a > "slow" subdirectory. Agreed. This was what I meant to say. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
Even if that wont prevent Sam's proposed information leak, I think this would be good to do. That way developers only see what they are affecting. Otherwise a developer might chase a red herring if they have Gmail or something open in the background and keep seeing spikes of memory are not caused by their page. On Jun 2, 2010, at 2:45 PM, Mikhail Naganov wrote: > Used memory count can be restricted to include only objects reachable > from the caller execution context. In this case, an app could only see > the amount of memory consumed by itself, not by the whole engine. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] About fixing "old" layout bugs
When there are only a couple tests that need new expectations, you can get away with committing your patch with the expectations for the platforms you have access to and then immediately grabbing the new expectations off the buildbots. There is currently no good way to address the cases where your patch causes many tests to need new results. There are ideas to make it better, but I don't think anyone is actively working on them. Specifically, the EWS bots could run the layout tests and give you access to the results. For now, with patches where you need to change many results and they're different on different platforms, you need to either get access to that platform, or get the help of someone who has access to it. Ojan On Wed, Jun 2, 2010 at 7:32 PM, Xianzhu Wang wrote: > Hi, > > I'm still wondering what the best practice is to deal with many updated > layout tests in a patch. It seems I must run the layout tests on all > effected platforms by myself to ensure a green build after committing the > patch, right? This is really difficult to me. Is there a easier way? > > Thanks, > Xianzhu > > 2010/6/2 Xianzhu Wang > > Hi, >> >> I'm new to webkit development, and I'd like to hear opinions about the >> problems I met. >> >> Now I'm trying to fix some "old" layout bugs, for example: >>* white space preceding ( >> https://bugs.webkit.org/show_bug.cgi?id=37261) >> * relative font-size (https://bugs.webkit.org/show_bug.cgi?id=18413) >> * line breaking around some punctuations ( >> https://bugs.webkit.org/show_bug.cgi?id=37698) >> >> Some people have warned me about the difficulty of fixing these bugs, and >> now I have realized it. Fixing the bugs themselves is not very difficult, >> for example, only 2 functional lines change can fix the first bug. However, >> the change will break more than 4000 existing layout tests mostly because >> trailing spaces preceding s in current expectations of the tests (for >> example, "PASS " vs "PASS"). I tried to rebaseline all effected layout tests >> (for now on mac only), and the patch is about 6MB (Sorry I overlooked the >> "Bigfile" option when I submitted the patch, so I split it into 4 parts). >> >> My questions are: >> >> 1. The bugs violate the standards and cause some site compatibility >> issues. However, because the bugs are old, some web developers might treat >> them as features and depend on them, so fixing them might break some >> existing pages. Is there any existing policy about this problem? Are these >> bugs worth fixing? >> >> 2. What's the best practice to deal with a patche containing many updated >> layout test expectations? Is there a good way to rebaseline the effected >> tests on all platforms? >> >> Thanks, >> Xianzhu >> >> > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
On Wed, Jun 2, 2010 at 2:45 PM, Mikhail Naganov wrote: > Used memory count can be restricted to include only objects reachable > from the caller execution context. In this case, an app could only see > the amount of memory consumed by itself, not by the whole engine. > I don't think this would change anything about my proposed problem. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making changes to our copy of the W3C CSS1 test suite
On Wed, Jun 2, 2010 at 6:20 PM, Darin Adler wrote: > >1) There’s one directory with a pristine copy of the W3C test suite, > with no WebKit changes. >2) If there are some tests that need to be fixed, fixed copies of those > individual tests would go into another directory. > So we would know that if css3-fixed-up/foo.html exists to skip css3-pristine/foo.html? 3) The broken tests can be run as-is, and we can land expected results to > reflect what the broken tests do. > > Perhaps I would think differently about some aspect of this if we had > introduced the “test expectations” concept for platforms other than > Chromium. It's a tradeoff. On the one hand, the test expectations approach lets you have a list of failing tests that you drive to 0. On the other hand, checking in failing expectations lets you know if you ever unintentionally change the the type of failure (e.g. it was failing for one reason and is now failing for a different reason due to your patch). If we intend to have a concerted, short-term effort to drive the failing tests to 0, then an expectations approach seems better. > There should be some set of tests that are faster to run that omits the > slower thorough tests. This was the original goal of “fast” but we have put > tests outside “fast” more or less at random. Why are “editing” tests outside > “fast”? Just the whim of the person who added them. Same comment on > directories like “accessibility”. > I don't like the concept of putting fast tests in a separate top-level directory. I want the tests to be grouped by what they're testing. If we want a way to run just the fast tests, we should just come up with a way of annotating tests as slow. Another option is that we could have a "slow" subdirectory. A real-world example, we have some very slow editing tests, but most of them are fast. We could move the slow ones into editing/slow or we could annotate them as slow in an expectations file. Then we add a --fast flag to run-webkit-tests that skips over slow tests. This does mean that we'll have slow subdirectories in many places (or a single file listing the slow tests), but at least tests will all be grouped by what they're testing. The test suites that are imported from elsewhere should go into directories > with clear names such as: > >ImportedTestSuites/W3C-CSS1 > > Rather than names like: > >css1 > This sounds great. It will make understanding the tests much easier. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal: Link http header support
David's right, Mozilla has it. https://developer.mozilla.org/en/link_prefetching_faq They support it for rel=next and rel=prefetch. Unfortunate, as I also think rel=subresource matters, and should be distinguished from prefetch for prioritization. - Gavin On Thu, Jun 3, 2010 at 4:15 PM, David Hyatt wrote: > Really? I thought they did, at least for stylesheets. > > dave > > On Jun 3, 2010, at 8:14 AM, Gavin Peters (蓋文彼德斯) wrote: > > No, no other browsers support it. There's a similar feature in Mozilla, > the LINK rel=prefetch item, but to my knowledge, Mozilla does not support > the Link header. > > On Wed, Jun 2, 2010 at 8:41 PM, Peter Kasting wrote: > >> On Wed, Jun 2, 2010 at 3:28 PM, Gavin Peters (蓋文彼德斯) > > wrote: >> >>> I'm starting hacking at adding support for the Link: http header. This >>> is described in RFC 2068, although not RFC 2616. As well, there's a current >>> internet draft describing it: >>> http://tools.ietf.org/id/draft-nottingham-http-link-header-10.html . >>> This header is being discussed in the IETF HTTP WG mailing list. Since it >>> was in HTTP 1.1 as first published, it is reserved, and legal to use today >>> for this purpose. >>> >> >> Is this supported in any other browsers? Do websites make use of it? >> >> I'm not saying you should necessarily stop if the answers are "no", but >> it's good to know the lay of the land. >> >> PK >> > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal: Link http header support
On Jun 2, 2010, at 5:28 PM, Gavin Peters (蓋文彼德斯) wrote: > I don't think I'll share much code . Try to share as much code as you can, assuming it makes sense to do so. We could always refactor common code into something like a CSSStyleSheetLoader class if we needed to. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal: Link http header support
Really? I thought they did, at least for stylesheets. dave On Jun 3, 2010, at 8:14 AM, Gavin Peters (蓋文彼德斯) wrote: > No, no other browsers support it. There's a similar feature in Mozilla, the > LINK rel=prefetch item, but to my knowledge, Mozilla does not support the > Link header. > > On Wed, Jun 2, 2010 at 8:41 PM, Peter Kasting wrote: > On Wed, Jun 2, 2010 at 3:28 PM, Gavin Peters (蓋文彼德斯) > wrote: > I'm starting hacking at adding support for the Link: http header. This is > described in RFC 2068, although not RFC 2616. As well, there's a current > internet draft describing it: > http://tools.ietf.org/id/draft-nottingham-http-link-header-10.html . This > header is being discussed in the IETF HTTP WG mailing list. Since it was in > HTTP 1.1 as first published, it is reserved, and legal to use today for this > purpose. > > Is this supported in any other browsers? Do websites make use of it? > > I'm not saying you should necessarily stop if the answers are "no", but it's > good to know the lay of the land. > > PK > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Support for showModalDialog in WebKit
Hi Darin - I have a tiny CL related to this, sitting around for a couple of days now - https://bugs.webkit.org/show_bug.cgi?id=40036. Would you be able to review it? Thanks, Prasad On Mon, May 24, 2010 at 10:29 AM, Prasad Tammana wrote: > > On Fri, May 21, 2010 at 8:29 PM, Darin Adler wrote: > >> On May 21, 2010, at 6:40 PM, Prasad Tammana wrote: >> >> > 2) Added code to invoke abortModal from NSWindowWillCloseNotification >> notification. >> >> I didn’t tell you do do that, and I don’t know why you’re calling >> abortModal. >> > > Sorry, you didn't tell me about the second step. That's part of my > description of the scenario in my original mail. I call abortModal to end > the modal loop created by runModalForWindow. > > Prasad > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to handle a new protocol for Blob.url support?
Does webcore have a 'protocol handler' abstraction that can be leveraged to add support for a new protocol scheme? I don't think it does, but an abstraction like that may help with this. On Wed, Jun 2, 2010 at 6:19 PM, Jian Li wrote: > This will probably work for most of the platforms, except the one that uses > multi-process architecture. How do we handle the case that a page is trying > to access a blob URL that is created in another process (assume the > accessing page is in the same security domain)? I think for the platform, > like Chromium, we can choose to delegate to the host to do the right job, > while all other platforms will share the same handling logic defined at a > higher level. > > In addition, we might need to hook up additional logic if we want to > support using it in the shared worker process. > > > > On Wed, Jun 2, 2010 at 6:08 PM, Darin Adler wrote: > >> On Jun 1, 2010, at 5:14 PM, Jian Li wrote: >> >> I am working on Blob.url support as defined in the latest version of File >> API (http://dev.w3.org/2006/webapi/FileAPI/). The Blob.url will return a >> URL that can be used to refer to the blob object in a resource request, like >> blobdata:f81d4fae-7dec-11d0-a765-00a0c91e6bf6. The blob object can represent >> a whole file, a partial file (created by Blob.slice), or a byte array >> (created by BlobBuilder defined in the FileWriter spec). What is the right >> place I can hook up with in order to interpret and process the blobdata >> request? Should it be in the WebKit library layer that will be implemented >> by individual platform or in the higher layer like what application cache >> does the work? >> >> >> Definitely a higher level. We don’t want to have to reimplement a feature >> like this for each platform. >> >> -- Darin >> >> > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Directory upload experimental feature
Also, I was simply pointing out existing behavior, not arguing for/against the zip file format. Dave From: Sam Weinig To: David Kilzer Cc: John Gregg ; webkit-dev@lists.webkit.org; Adele Peterson Sent: Wed, June 2, 2010 11:28:11 AM Subject: Re: [webkit-dev] Directory upload experimental feature I think this is only true for Mac OS X style bundles, not all folders. On Wed, Jun 2, 2010 at 3:44 AM, David Kilzer wrote: > Other alternatives? > > >I believe Safari will zip a folder and send it as a single file for you if you >attach a folder to a file upload element instead of an individual file. > > >Dave > > > > > From: John Gregg >To: Sam Weinig >Cc: webkit-dev@lists.webkit.org >Sent: Tue, June 1, 2010 3:09:00 PM >Subject: Re: [webkit-dev] Directory upload experimental feature > > >>My proposal for that is that all the files would be listed in the form >>submission the same way as if it were a , but in >>the Content-Disposition header, the filename component would contain the path >>information. >> > >One alternative idea would be add a "path" component to the >Content-Disposition header alongside the filename which remains unchanged, but >I think that would be a much more difficult approach. Other alternatives? > > >Example follows. > > > -John > > > >If you are have these files >/home/John/photos/vacation/1.jpeg >/home/John/photos/vacation/2.jpeg >> >/home/John/photos/conference/1.jpeg > > >and choose "photos" from the directory picker, you'd end up with >input.files[0].name = "1.jpeg" >input.files[0].path = "photos/vacation/1.jpeg" >input.files[1].name = "2.jpeg" >input.files[1].path = "photos/vacation/2.jpeg" >input.files[2].name = "1.jpeg" >input.files[2].path = "photos/conference/1.jpeg" > > >Your POST would look like >Content-type: multipart/form-data; boundary=WebKitFormBoundaryFoo > > >WebKitFormBoundaryFoo >Content-Disposition: form-data; name="input"; filename="photos/vacation/1.jpeg" >Content-Type: image/jpeg > > > > > >WebKitFormBoundaryFoo >Content-Disposition: form-data; name="input"; filename="photos/vacation/2.jpeg" >Content-Type: image/jpeg > > > > > >WebKitFormBoundaryFoo >Content-Disposition: form-data; name="input"; >filename="photos/conference/1.jpeg" >Content-Type: image/jpeg > > > > > > > >On Sat, May 29, 2010 at 10:22 AM, Sam Weinig wrote: > >How will the directory structure and all the files therein be represented in >the form submission? >> >> >>-Sam >> >> >>On Fri, May 28, 2010 at 3:17 PM, John Gregg wrote: >> >>Hi WebKit, >>> >>> >>>I recently proposed adding directory upload support to HTML via a new >>> attribute to whatwg@, and the discussion arrived at "try it out". >>>Having written some code I think I have something that works pretty well, >>>and I'd like to land it on an experimental basis in WebKit, but want to >>>reach out early before trying to put any code in the tree. The plan that >>>comes to mind is a new ENABLE_DIRECTORY_UPLOAD flag, but I'm completely open >>>to other options. >>> >>> >>>Background (cf. the whatwg thread >>>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-April/025764.html): >>> - The use case for this is a photo album or file manager web application, >>> which wants the user to easily choose an entire directory to recursively >>> upload, while preserving the sub-directory structure. >>> - The reason for the new attribute is to signal the UA to show a native >>> folder-picker rather than a file-picker, which on most OSs are two distinct >>> dialogs. >>> >>>The approach I'm using has 2 parts and is a small amount of WebCore code >>>(about 200 lines). >>> - Extend HTMLInputElement to support the directory attribute, which is >>> passed up via FileChooser allowing the UA to display a folder-picker. UA >>> enumerates all the files and returns them in the normal way. >>> - Extend File to have a File.path property, which contains the path >>> information starting from the chosen directory as the root. >>> HTMLInputElement is responsible for generating these values from the list >>> of files when the directory attribute is set. >>> >>> >>>Thoughts? >>> >>> >>>Thanks, >>> -John >>>___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Extending JavaScript in WebKit
Hi, I wrote a blog post about this some time ago while trying to understand the same thing. Maybe it will help you, http://uselessbyte.blogspot.com/2009/12/adding-custom-javascript-bindings-to.html Btw, I think this question belongs to webkit-help not webkit-dev. Niklas On 3 jun 2010, at 14.56, Wadii Guedria wrote: > Hi, > > I am trying to extend javascript to invoke custom C /C++ code in webkit. I > would like to make a glue between C/C++ code and javascript functions via > webkit. > I think that it's possible with JavaScriptCore API's, but I dont know how. > Any suggestions are welcome. > > regards, > Wadii ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal: Link http header support
No, no other browsers support it. There's a similar feature in Mozilla, the LINK rel=prefetch item, but to my knowledge, Mozilla does not support the Link header. On Wed, Jun 2, 2010 at 8:41 PM, Peter Kasting wrote: > On Wed, Jun 2, 2010 at 3:28 PM, Gavin Peters (蓋文彼德斯) > wrote: > >> I'm starting hacking at adding support for the Link: http header. This is >> described in RFC 2068, although not RFC 2616. As well, there's a current >> internet draft describing it: >> http://tools.ietf.org/id/draft-nottingham-http-link-header-10.html . >> This header is being discussed in the IETF HTTP WG mailing list. Since it >> was in HTTP 1.1 as first published, it is reserved, and legal to use today >> for this purpose. >> > > Is this supported in any other browsers? Do websites make use of it? > > I'm not saying you should necessarily stop if the answers are "no", but > it's good to know the lay of the land. > > PK > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to handle a new protocol for Blob.url support?
On Thu, Jun 3, 2010 at 2:08 AM, Darin Adler wrote: > On Jun 1, 2010, at 5:14 PM, Jian Li wrote: > > I am working on Blob.url support as defined in the latest version of File > API (http://dev.w3.org/2006/webapi/FileAPI/). The Blob.url will return a > URL that can be used to refer to the blob object in a resource request, like > blobdata:f81d4fae-7dec-11d0-a765-00a0c91e6bf6. The blob object can represent > a whole file, a partial file (created by Blob.slice), or a byte array > (created by BlobBuilder defined in the FileWriter spec). What is the right > place I can hook up with in order to interpret and process the blobdata > request? Should it be in the WebKit library layer that will be implemented > by individual platform or in the higher layer like what application cache > does the work? > > > Definitely a higher level. We don’t want to have to reimplement a feature > like this for each platform. > Bonus points if whatever you come up with for Chromium shares as much code as possible with WebKit2. > > -- Darin > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Extending JavaScript in WebKit
Hi, I am trying to extend javascript to invoke custom C /C++ code in webkit. I would like to make a glue between C/C++ code and javascript functions via webkit. I think that it's possible with JavaScriptCore API's, but I dont know how. Any suggestions are welcome. regards, Wadii ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] free functions
On Tue, May 25, 2010 at 10:01 AM, Darin Adler wrote: > On May 25, 2010, at 7:54 AM, Chris Jerdonek wrote: > >> I sometimes come across public member functions whose implementations do not >> depend on private data. >> >> There is a school of thought that such functions are better non-member >> because it reduces the number of functions coupled to private data. On the >> other hand, I've heard the argument that making such functions free creates >> naming issues -- it's not clear to the caller in which header file to find >> the free function. >> >> My question for WebKit is whether naming considerations outweigh >> encapsulation considerations. And if so, is there a naming convention or >> otherwise that we can use to make finding free functions easier? > > We do need our classes to be smaller so we can understand the structure of > the code. The encapsulation benefits of having a much smaller number of > members in a class are well worth some cost. But there are at least two > considerations that come into play when replacing a member function with a > free function: > > 1) Free functions still have to go in some header/source file. The usual > rule for finding a function is to look for a file named based on the class. > Without a class name we have to do something to make it practical to find the > functions in the source tree without a lot of searching. > > 2) Free functions need names that are clear and unambiguous with no > context other than the WebCore namespace. We try to keep member function > names short, and we can do so in part because they have a class name context. > The same function as a free function will almost certainly need a longer > name. Each time we create a free function we have to think about what an > appropriate name is; it’s a mistake to leave the same short name that was > previously used for a class member. > > Another possible way to get encapsulation benefits with fewer of the other > problems is to group functions into classes or namespaces that have no data > and nothing else private. This may be helpful if the class or namespace name > has a good name with a clear concept. Would the following simple convention be an acceptable option? A free function in a header file could go in a nested namespace whose name is the name of the header file followed by "Functions" (as in "free functions"). An example in Chrome.h might be-- WebCore::ChromeFunctions::applyWindowFeatures(Chrome*, const WindowFeatures&); Would adding such a non-member function be preferable to adding to the Chrome class a public member function that didn't depend on private Chrome data? The encapsulation discussion above suggests it would. I'm just trying to think of a simple alternative so the default need not always be to add another member function. For comparison, we have essentially 8 files whose file name ends in "Functions": JavaScriptCore/API/JSCallbackObjectFunctions.h JavaScriptCore/runtime/JSGlobalObjectFunctions.* JavaScriptCore/wtf/HashFunctions.h JavaScriptCore/wtf/StringHashFunctions.h WebCore/bindings/js/JSPluginElementFunctions.* WebCore/dom/PositionCreationFunctions.h WebCore/xml/XPathFunctions.* WebKit/mac/Plugins/WebNetscapeDeprecatedFunctions.* (For files like these, we would probably not want to use a convention like the above.) --Chris ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
