[webkit-efl] Use of pimpl idiom for Ewk classes

Kangil Han kangil.han at samsung.com
Fri Oct 19 00:44:09 PDT 2012


> On Thu, Oct 18, 2012 at 11:56 AM, Dumez, Christophe
> <christophe.dumez at intel.com> wrote:
> > Hi,
> >
> > Mikhail and I are currently working on refactoring the Ewk classes to
> make
> > them more C++-like, more convenience to use and less bug-prone.
> > As part of this work, we came out with a proposal: Use pimpl idom for
> Ewk
> > classes.
> >
> > The Ewk classes are currently defined in the private headers, with all
> their
> > members public. The private headers also usually contain C-style
> functions
> > to interact with the Ewk class from inside WebKit.
> > Now, we would like to get rid of those private C functions and replace
> them
> > with C++ methods in the Ewk class. The issue is that the Ewk class
> members
> > are currently public meaning we can alter the members directly from
> outside
> > the Ewk class implementation and bypass those class methods.
> >
> > At the same time, we don't want to make all the Ewk class members
> private
> > and create getter / setter methods for all of them. Not only this means
> a
> > lot of refactoring work and extra code, but also, this means that are
> public
> > C API implementation will need to go through those getters / setters as
> > well, instead of interacting with the class members directly.
> >
> > We therefore thought of using the pimpl idiom so that the class members
> are
> > now stored in a POD struct in the cpp file. This effectively prevents
> access
> > to them from code other than our public C API and Ewk class methods,
> which
> > is what we want. The C API functions can still directly interact with
> the
> > Ewk class members which is convenient. We can get rid of all C functions
> in
> > the private headers and replace them with Ewk class methods. Therefore,
> the
> > coding style in WK2 EFL port implementation with be more C++ oriented.
> >
> > I created a meta bug for this task:
> > https://bugs.webkit.org/show_bug.cgi?id=99696
> >
> > I also wrote a first patch to show what the result looks like for the
> > Ewk_Download_Job class. The patch also adds convenience macros to
> > ewk_private.h to make pimpl idiom usage simpler and less error-prone:
> > https://bugs.webkit.org/show_bug.cgi?id=99697
> >
> > We hope you like the result as much as we do.
> > If everyone agrees, Mikhail and I are planning to port other Ewk classes
> to
> > this proposal and update the WebKit EFL coding style.
> >
> 
> Is it really necessary to make this a Qt-like pimpl?
> 
> AFAIK Qt has this opaque d-pointer to keep ABI compatibility across
> releases. Since we are working on private code, I don't see need for
> this. Will just complexity to the code and extra pointers
> dereferences.
> 

I think this point of view is really impressive. :)
Given information on web, pimpl idioms is usually used when we hide
information from the outer program coupled with shared library.
This is because we don't have to or can't rebuild all outer applications
when data structure need modification.
As tmpsantos pointed, we are discussing about private functions.

> Don't get me wrong, the refactoring is indeed necessary (but can be
> done differently). What I'm questioning here is the need of these
> macros and the "d->private" idiom. The change bellow is fine, removed
> C-ism from the code:
> 

Yes, I want to avoid macro usage as much as we could since it is C-ism.

> -     uint64_t downloadId = ewk_download_job_id_get(ewkDownload);
> +    uint64_t downloadId = ewkDownload->id();
> 
> But I would write Ewk_Download_Job::id() like this:
> 
> uint64_t Ewk_Download_Job::id() const
> {
>     return m_downloadProxyId;
> }
> 
> Instead of:
> 
> uint64_t Ewk_Download_Job::id() const
> {
>     return d->downloadProxy->downloadID();
> }
> 
> Why not instead of creating a Ewk_Download_Job_Data you store the
> information you need inside Ewk_Download_Job and mark as private
> attributes?
> 
> Cheers,
> _______________________________________________
> webkit-efl mailing list
> webkit-efl at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-efl



More information about the webkit-efl mailing list