From kde-core-devel Mon Oct 09 16:43:02 2006 From: Leo Savernik Date: Mon, 09 Oct 2006 16:43:02 +0000 To: kde-core-devel Subject: Re: Using scripting languages for KDE4 main modules Message-Id: <200610091843.03482.l.savernik () aon ! at> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=116041233618165 Am Sonntag, 8. Oktober 2006 20:21 schrieb Aaron J. Seigo: > > > i don't think it's too much to ask for kjs or qsa. they are both > > > lightweight and at least kjs is already in use on your desktop if you > > > use konqi. > > > > Is KJS the same code that renders javascript inside pages? If yes, its > > yes > > > used, but only when web browsing certain pages. Sure, KDE user should > > always have a Konqueror window open and they should use it as their > > browser, so you have a point here. ;-) > > =) additionally, if no one has issues with it as part of the default web > browser, why the issues with it elsewhere? The fundamental problem with scripting languages, be it purely interpreted like kjs or jitted like perl, which people tend to forget is this: The real memory hog is the representation of the abstract syntax tree and all accompanying management objects. For *every* statement, *every* variable, *every* call, and *every* reference you need a dedicated object in memory *which cannot be shared* (to the contrary of the native script interpreter's machine code which, as an .so, *is* shared). Those cannot be shared because they represent *different* scripts which are going to be executed. Even jitted script-languages provide dynamic introspection and evaluation features which still forces the engine to keep elaborate AST-information around. Therefore, really basic features like a *clock*-applet must not even remotely be considered for contamination by scripts. (So, maybe there'll be a Dashboard-MacOSX-clock in javascript, but the basic desktop must contain a clock-clock in C++ which fulfills nothing but the tasks of a clock in a memory-efficient and performant way.) mfg Leo