[Qbs] Language Proposal: A generic `Item{}` for classifying bindable objects. Christian Kandeler

[hug-animals]

General Update

- It was very easy to start working on the project.
- Built the QBS project with Qt 5.15 (6.3 had issues with a legacy dependency based on QtScript)
- Tested it with LD_PRELOAD=/Path/To/File.so

Responding to Иван Комиссаров"Maybe Object (or Gadget/smth else since JS has “object” type already) as it is not a generic Item used in other items would be better."
Object{}​ makes sense. I had been using Class{}​ in my code, although that seems a bit misleading. Ill make a small list of things that come to mind:

- Object
- Class
- Item
- Gadget
- Schema
- Nest
- Struct
- Sub

Responding to Michael
Syntax:
property MyItem prop​
That is an absolutely excellent idea. I prefer this the most because it allows us to create psuedo-types. Presuming MyItem would be imported, I see only one small drawback, in that it would also require a seperate file for even small classifications [That might be neccessary for compilation however]. That would end up polluting the import section, although probably not in the main project/product file.

property var feed: Item {

I also agree that this seems to be the most sensible syntax. id: or name: seems redundant, and makes checking for map key conflicts a bit more complex.

Encapsulation:
"Access into nested items isnt explicitly supported in QML"
Hard to know what you mean exactly, because you can set properties of nested items. Could you give an example of what is explicitly prohibited?

"If I understand correctly, your items are just typesafe JSObjects"
Sadly I am a bit vague on exactly what is going on in the backend in qbs, whether that is literal or pseudo javascript being used. Items appear to have a QMap with Pointers to:

> class Value; // base class
> using ValuePtr = std::shared_ptr<Value>;
> using ValueConstPtr = std::shared_ptr<const Value>;
>
> class ItemValue;
> using ItemValuePtr = std::shared_ptr<ItemValue>;
> using ItemValueConstPtr = std::shared_ptr<const ItemValue>;
>
> class JSSourceValue;
> using JSSourceValuePtr = std::shared_ptr<JSSourceValue>;
> using JSSourceValueConstPtr = std::shared_ptr<const JSSourceValue>;
>
> class VariantValue;
> using VariantValuePtr = std::shared_ptr<VariantValue>;
> using VariantValueConstPtr = std::shared_ptr<const VariantValue>;

When I tested in qbs, I could only produce JSSourceValues though, so maybe? But when I look at the class, I am not seeing how the source code it stores is being interprted.

Devils Advocate
"Why has no one needed this in QML thus far?"
That is a very good question. Thank you for asking.
I do not have a perfect answer, because while I have worked on about half a dozen qml projects, that was around 2016.
From what I remember, QML is far more flexible, with Item{}​ being its generic container that can be used in anything.
QBS on the other hand is incredibly static with its items, and so while I can make my own Probe with its own properties, I can not make a Probe within a Probe, and so even if I wanted to say set a sub property, it just is not possible. QML on the other hand can set properties of nested items, I think you just have to be a bit cognisant of compilation order.

Parser Will Need Work
True and probably a fair bit, but I consider that an afterthought. The parser has to be fixed either way since its borrowed and a bit misleading.

Thoughts on Existing QBS Code

- The code in general is fairly great quality.
- It conforms to what I have seen in general from formal Qt code, so no surprises there.
- I do tend to think though that Qt's internal code is a bit messy and which makes it unweildly ( Better than a lot of projects though )
- And so grasping the internal structure of the API is quite difficult.
- As I have been editting the code, I have been rearranging functions. While I am unlikely to include that formatting in a patch, if I do share my code, just a bit of a heads up on the crazy diff. A lot of that is just formatting and style so I can better grasp the structure.

What are you vague on? [ Spitballing here - Feel free to ignore ]

- Why would the item pool use `std::vector<Item *> m_items;` instead of a QList ( Or QVector ) ? I imagine it was a performance consideration, but it always puzzles me to see stdlib in most qt code.

- Should Project and Product remain the only top level Items? Or would there be reason to let GenericItem{}​ do so also? I am thinking to keep it as is.
- There are three Values -- Item, JSSource, and Variant. I have only been able to create JSSource when making a qbs file. What are the other two used for?

That is it for now. Thank you for your feedback.

Sent with [Proton Mail](https://proton.me/) secure email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qbs/attachments/20220906/b19de2c7/attachment.htm>