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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Feb 16 05:26:20 PST 2012


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





--- Comment #13 from Tomasz Morawski <t.morawski at samsung.com>  2012-02-16 05:26:20 PST ---
(In reply to comment #12)
Hi,
Sorry for long absence.

> 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.
I have moved our discussion to webkit-efl list where it is a better place for it. 

> > > 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.
My main intention was to obtain small, easy and clear API for final user with few functions to create and manipulate objects and put all ewk_js implementation to internal port files. It is a good idea to use Eina_Model and Eina_Value but only internally. These objects should be encapsulated by few public API functions. This way will allow to make browser application independent to future Eina_* object changes, library and it will be more save due to that API functions could be properly handled. 
Anyway, why Ewk_Js_Class_Meta will be not need?

-- 
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