[Webkit-unassigned] [Bug 77337] [EFL] Refactor ewk_js files.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Feb 9 08:17:54 PST 2012


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





--- Comment #12 from Raphael Kubo da Costa <kubo at profusion.mobi>  2012-02-09 08:17:53 PST ---
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > BTW I don't know why EFL port don't follow this rule and put every thing into ewk_private.h file?
> > 
> > Mostly because that's what the EFL themselves do.
> But why into one, single the ewk_private.h file? It is not logic.

It's just a convention.

> Even EFL like ecore, evas etc. libraries use more then one private file for example the ecore uses 17 such private files. 

You can consider evas has a single evas_private.h that's got 1k lines; if you compare it with ecore, you should consider ewk equivalent to one ecore module.

Note I am not saying I agree with this, but rather explaining why things were done this way the last time the port was rewritten.

> > This could all be replaced with Eina_Model (even if Eina_Model itself needs some new code for that).
> How it may work? Do you suggest to define Ewk_JS_Object, Ewk_JS_Class_Meta, Ewk_JS_Variant, Ewk_JS_Method, Ewk_JS_Property, Ewk_JS_Class_Meta as Eina_Model object inside ewk_js.h file?

Eina_Model already has the concept of properties, Eina_Value is a better Ewk_JS_Variant, Ewk_JS_Class_Meta shouldn't be needed etc. I haven't thoroughly thought about how it would work exactly, but the point is to leverage what already exists in Eina as much as possible.

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



More information about the webkit-unassigned mailing list