Re: [Development] Proposal for an efficient and robust (de)serialization mechanism working with Qt-supported data
> > Suggestions: > > pack, wad (another indirect Doom reference), bale, herd, doss, > > transfigure (probably too long) > > I cannot resist to suggest QTransmogrifier [1] > Seriously, QBind is akin to GUI data binding and SQL parameter binding but > more specialized so I would just pick a more descriptive name. Also, since it > is a generic function class (not a functor), I would keep the verb Bind in > it. And since it addresses only values (object graphs must be somehow encoded > before they can be 'bound'), I suggest: > - QValueBind (= QBind, the generic function class with bind(QValue&& v, T t) > overloads) > - using QValue = Val as the start point of the fluent interface > allowing to describe any T 'value' in a generic way > > I am also not comfortable with 'Cursor' (a non-owning unique pointer used to > bypass illegal or useless calls to the fluent interface) which conflicts with > the usual definition of SQL cursors. You know, I was really tempted to suggest Transmogrifier but thought I would be the only one. I really do think it's a great name! Just a little too long. That said, it is an awesome name and very unique can't can't be mistaken for being anything else. However "bindvalue" (the transposition of [value, bind]) is already a thing. https://doc.qt.io/qt-5/qsqlquery.html#bindValue , Which I would like to avoid because there could be serialization to SQL.. Thought of another one, "flow" ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal for an efficient and robust (de)serialization mechanism working with Qt-supported data
-Original Message- From: Jason H > > My only remaining comment is QBind is rather ambiguous. > > We already have "bind" used as for SQL parameters. Bind is also used for IP > > ports, Boost uses "bind" for connections. "Data binding" is another thing > > as well usually to bind data to UI elements. > > Could it be called something else? > > I realized that I broke my own rule of criticizing something without > suggesting a replacement. > I don't have anything that jumps out, but in python, the struct module has > pack() which us just as long and not used (to my knowledge) > > Suggestions: > pack, wad (another indirect Doom reference), bale, herd, doss, > transfigure (probably too long) I cannot resist to suggest QTransmogrifier [1] Seriously, QBind is akin to GUI data binding and SQL parameter binding but more specialized so I would just pick a more descriptive name. Also, since it is a generic function class (not a functor), I would keep the verb Bind in it. And since it addresses only values (object graphs must be somehow encoded before they can be 'bound'), I suggest: - QValueBind (= QBind, the generic function class with bind(QValue&& v, T t) overloads) - using QValue = Val as the start point of the fluent interface allowing to describe any T 'value' in a generic way I am also not comfortable with 'Cursor' (a non-owning unique pointer used to bypass illegal or useless calls to the fluent interface) which conflicts with the usual definition of SQL cursors. Arnaud [1] https://calvinandhobbes.fandom.com/wiki/Transmogrifier ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal for an efficient and robust (de)serialization mechanism working with Qt-supported data
> My only remaining comment is QBind is rather ambiguous. > We already have "bind" used as for SQL parameters. Bind is also used for IP > ports, Boost uses "bind" for connections. "Data binding" is another thing as > well usually to bind data to UI elements. > > Could it be called something else? I realized that I broke my own rule of criticizing something without suggesting a replacement. I don't have anything that jumps out, but in python, the struct module has pack() which us just as long and not used (to my knowledge) Suggestions: pack wad (another indirect Doom reference) bale herd doss transfigure (probably too long) ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal for an efficient and robust (de)serialization mechanism working with Qt-supported data
My only remaining comment is QBind is rather ambiguous. We already have "bind" used as for SQL parameters. Bind is also used for IP ports, Boost uses "bind" for connections. "Data binding" is another thing as well usually to bind data to UI elements. Could it be called something else? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Gerrit-admin] Cherry-pick mode for 5.12
> On 3 Sep 2019, at 09:12, Allan Sandfeld Jensen wrote: > > On Tuesday, 3 September 2019 07:53:29 CEST Liang Qi wrote: >> It happened so fast this time. >> >> But 5.12.5 was branched out before this cherry-pick mode change on 5.12 >> branch, I plan to do the 5.12.5->5.12->5.13 merges after 5.12.5 is out. Is >> it OK? > > That sounds good. Otherwise we might need to cherry-pick up. Yes, we’ll need to make sure everything that was committed before we entered cherry-pick mode is merged. Cheers, Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Gerrit-admin] Cherry-pick mode for 5.12
On Tuesday, 3 September 2019 07:53:29 CEST Liang Qi wrote: > It happened so fast this time. > > But 5.12.5 was branched out before this cherry-pick mode change on 5.12 > branch, I plan to do the 5.12.5->5.12->5.13 merges after 5.12.5 is out. Is > it OK? That sounds good. Otherwise we might need to cherry-pick up. 'Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
