config.json, private variable optimization and job-inheritance issues

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

config.json, private variable optimization and job-inheritance issues

Gaetan de Menten
Hi again,

The other day, I noticed a piece of code I had recently ported to 0.8
didn't work anymore with the "build" version. As I expected, it turned
out to be a "private variables optimization" issue: I inherited from
qx.ui.table.model.Simple and reused _rowArr (since it was protected
and not private in 0.7): why was it changed to private anyway?

My issue is that to simply turn off "private variable optimization", I
had to copy-paste a whole bunch of stuff from base.json: the
"build-script", "build-files", "build-resources" and "build" jobs, as
well as the "common" job (that I renamed since I already had a job
named "common").

Is there another easier/quicker way? Does it really make sense to
limit the jobs you can reuse by the explicit "export", wouldn't it be
better to simply "export" all jobs? I understand you don't want all
jobs to appear when doing a ./generate "?", but limiting exports is
painful. I see two other solutions to this: 1) explicitly export all
these jobs, so that I could have simply inherited from build-script
and change the "optimize" key. 2) introduce *yet* another variable in
the "let" section with optimizations.


Another question: in the documentation for the "compile-dist" key,
there is this:
format : true/false, for simple output formatting

Could anybody explain (preferrably in that documentation) what does
that mean exactly?

Also, it is documented as true/false, yet it is "on" in base.json.
I guess "on" is equivalent to true, but it's still incorrect...

PS: please don't take my repeated criticism badly. I really
appreaciate what you guys are doing. It's great!
--
Gaëtan de Menten
http://openhex.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: config.json, private variable optimization and job-inheritance issues

thron7


Gaetan de Menten wrote:

> Hi again,
>
> The other day, I noticed a piece of code I had recently ported to 0.8
> didn't work anymore with the "build" version. As I expected, it turned
> out to be a "private variables optimization" issue: I inherited from
> qx.ui.table.model.Simple and reused _rowArr (since it was protected
> and not private in 0.7): why was it changed to private anyway?
>
> My issue is that to simply turn off "private variable optimization", I
> had to copy-paste a whole bunch of stuff from base.json: the
> "build-script", "build-files", "build-resources" and "build" jobs, as
> well as the "common" job (that I renamed since I already had a job
> named "common").
>
> Is there another easier/quicker way?

Not just yet, but see http://bugzilla.qooxdoo.org/show_bug.cgi?id=1417 .


>  Does it really make sense to
> limit the jobs you can reuse by the explicit "export", wouldn't it be
> better to simply "export" all jobs? I understand you don't want all
> jobs to appear when doing a ./generate "?", but limiting exports is
> painful.

Well, you've given the arguments yourself. Since 0.8 introduced so many
new features a lot was geared to make it easier for entry-level use
cases. It seemed more important to limit the amount of "name space
pollution" for the importing config, both to keep the job list short and
relevant, and to limit potential name clashes. But once you want to do
more with imported jobs the "export" gets in the way, I've had this
issue myself.

> I see two other solutions to this: 1) explicitly export all
> these jobs, so that I could have simply inherited from build-script
> and change the "optimize" key. 2) introduce *yet* another variable in
> the "let" section with optimizations.
>  

I don't like an abundance of global 'let' macros; this was pretty much
the situation with the Makefile-based build system, and I was not
particularly fond of it (but I had feedback of users that explicitly
liked it). I'd rather have structured data.

I could think of other solutions as well, e.g. only listing "runnable"
jobs with './generate.py ?', but importing all of them.


>
> Another question: in the documentation for the "compile-dist" key,
> there is this:
> format : true/false, for simple output formatting
>
> Could anybody explain (preferrably in that documentation) what does
> that mean exactly?
>  

Some sensible line breaks are introduced in the output. It's a coars
means to improve readability.

> Also, it is documented as true/false, yet it is "on" in base.json.
> I guess "on" is equivalent to true, but it's still incorrect...
>  

I've changed the online docs.

> PS: please don't take my repeated criticism badly. I really
> appreaciate what you guys are doing. It's great!
>  

Ok.

Thomas


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: config.json, private variable optimization and job-inheritance issues

Gaetan de Menten
On Mon, Oct 13, 2008 at 2:57 PM, thron7 <[hidden email]> wrote:

> Gaetan de Menten wrote:
>
>>  Does it really make sense to
>> limit the jobs you can reuse by the explicit "export", wouldn't it be
>> better to simply "export" all jobs? I understand you don't want all
>> jobs to appear when doing a ./generate "?", but limiting exports is
>> painful.
>
> Well, you've given the arguments yourself. Since 0.8 introduced so many
> new features a lot was geared to make it easier for entry-level use
> cases. It seemed more important to limit the amount of "name space
> pollution" for the importing config, both to keep the job list short and
> relevant, and to limit potential name clashes.

Well, this does not apply if you import the jobs "as"...

> But once you want to do
> more with imported jobs the "export" gets in the way, I've had this
> issue myself.
>
>> I see two other solutions to this: 1) explicitly export all
>> these jobs, so that I could have simply inherited from build-script
>> and change the "optimize" key. 2) introduce *yet* another variable in
>> the "let" section with optimizations.
>>
>
> I don't like an abundance of global 'let' macros;

FWIW, me neither...

> this was pretty much
> the situation with the Makefile-based build system, and I was not
> particularly fond of it (but I had feedback of users that explicitly
> liked it). I'd rather have structured data.
>
> I could think of other solutions as well, e.g. only listing "runnable"
> jobs with './generate.py ?', but importing all of them.

That's exactly what I was thinking... I mean, only listing explicitly
"exported" jobs, but still be able to inherit/extend the non exported.

--
Gaëtan de Menten
http://openhex.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel