[QBS] syntactic sugar

[Oswald Buddenhagen]

On Tue, Feb 28, 2012 at 12:51:40PM +0100, ext jan at jkrieger.de wrote:
> ... and thanks for the warm welcome on the mailing list!
> 
> > > > - the same for this construct:
> > > >     Group {
> > > >       condition: qbs.target == "windows"
> > > >       files: [
> > > >         "harddiskdeleter_win.cpp",
> > > >         "blowupmonitor_win.cpp",
> > > >         "setkeyboardonfire_win.cpp"
> > > >       ]
> > > >     }
> > > >    why not simply write:
> > > >     Group (condition: qbs.target == "windows") {
> > > >       files: [
> > > >         "harddiskdeleter_win.cpp",
> > > >         "blowupmonitor_win.cpp",
> > > >         "setkeyboardonfire_win.cpp"
> > > >       ]
> > > >     }
> > >
> > > I cannot see why this is simpler. You're adding two more characters
> after all. ;-)
> > >
> > he certainly meant to remove the "condition: " part, riiiiight? ;)
> 
> yeah that's what I meant ...so the example really should look like this:
>     Group (qbs.target == "windows") {
>       files: [
>         "harddiskdeleter_win.cpp",
>         "blowupmonitor_win.cpp",
>         "setkeyboardonfire_win.cpp"
>       ]
>     }
> 
> 
> 
> > - while it isn't, this very much looks like imperative programming
> 
> as you said ... it isn't, it's just a way of bringing conditions to a
> distinctive place, they are there anyways. It does not extend the
> possibilities already provided by condition: ... but it makes reading the
> code much easier (IMHO)
 
> > - we impose more rules on the structure of the files
> 
> that's true, but I think it will also improve readability,
> 
and it will make the tooling harder. additional structure means
additional logic to deal with it.

> > - we get a symmetry problem with other conditional nodes, e.g.,
> >   Properties. so make that IfGroup, ElseGroup, ElifGroup and
> >   IfProperties, ... instead? it gets ugly.
> 
> couldn't you just maky any node possibly conditional? So if there is a
> condition in (...), then only evaluate that node, if the condition
> evaluates to true.
> 
that would work for Properties. Group has "deeper meaning", so you would
need to nest the Group into the If.

> > - it's yet farther away from "normal" qml
> 
> that's true, but is this really an argument, as the qbd is another
> application, so why shouldn't we extend the underlying syntax definition to
> meet our needs? Asked theother way round: wouldn't it be nice to have the
> same feature in QML (didn't work with it yet, because I don't need it for
> my applications, but I think the same syntactic sugar could be nice there
> too)?
> 
i don't think so ... (to start with, there are generally no condition
properties).