[Webkit-unassigned] [Bug 96201] [EFL][WK2] WKEinaSharedString needs a function to adopt eina stringshare.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=96201





--- Comment #12 from Byungwoo Lee <bw80.lee at samsung.com>  2012-09-10 02:57:57 PST ---
(In reply to comment #11)
> > > Is it ok to use WKAdoptTag (adoptWK) for eina_stringshare even if it is not a WK api object?
> > 
> > I think yes, unless we want to introduce our own tag, I would use existing
> > one..
I think using WKAdoptTag for eina_stringshare can make human mistakes or misunderstanding, because some related template functions and class (e.g. WKRetainPtr, adoptWK()...) are also opened by cpp apis.

If a constructor uses WKAdoptTag for adopting eina_stringshare, api user can try to use adoptWK() function for eina_stringshare, because it already used in the header file.

How about your opinion?

> Another option is to add a new static member like 'static WKEinaSharedString fromEinaStringShare(Eina_Stringshare*);'
Ok, I think this is the issue about static function and friend function.

I also thought about this, and followed the way that adoptPtr() or adoptRef() is designed because it is slightly easy for api users.

With static function,
create sharedstring by adoption will be as below
WKEinaSharedString string = WKEinaSharedString::fromEinaStringShare(eina_stringshare_add(testString))

And with friend function,
create sharedstring by adoption will be as below
WKEinaSharedString string = adoptEinaStringShare(eina_stringshare_add(testString))

after we added below line in the header file.
+ using WebKit::adoptEinaStringShare(...);

I prefer the second personally (for an api user), but If there is some reason that this should be a static function, I'll change it.

Thanks for your comments :)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.