| 29 Nov 2021 |
 kitsune | The nice thing about the pattern is that it's possible to allow lambdas and then you can run practically any piece of read-only code on the event but only if the current state has it. So alternatively it can be auto membership = room->runOnCurrentState([] (const RoomMemberEvent& e) { return e->membership(); }); | 08:17:22 |
|  wh1 joined the room. | 09:38:54 |
| kitsune | Alternatively, I can break the current convention that Room::getCurrentState() never returns null pointers and return nullptr instead of a stub event. | 09:49:33 |
| kitsune | By the way, I stand corrected on "hundreds, maybe thousands" - 0.6 has a problem with stub state proliferation but I fixed it sometime ago in 0.7, so at least the library code almost doesn't cause creation of stub events. | 09:51:26 |
| kitsune | That code though still requires events be default-constructable, for which there's no other good reason. | 09:52:16 |
 Tobias Fella | I'm not sure if i understand it correctly, what would the type of membership be in the first example of the new syntax? A pointer that could be nullptr? | 12:08:42 |
| Tobias Fella | * I'm not sure if i understand it correctly, what would the type of membership be in the first example of the new syntax? A pointer that could be nullptr? | 12:09:12 |
| kitsune | The output from runOnCurrentState is always of type of the function object or function you pass to it. If there's no event, it will return a default-constructed value. This is really to turn endless if (const auto e = getCurrentState<...>(...)) return e->something(); else return {}; things into something more compact - there's a pile of locations benefitting from non-null convention of getCurrentState(). | 12:20:53 |
| kitsune | That being said, after scouting through the code of Quotient, Quaternion and NeoChat I find that both getCurrentState() (that can return nullptr) and runOnCurrentState() can be quite useful, depending on the case. Sometimes you really want to treat the no-such-state case in a different enough way to warrant getCurrentState(); but often what you want is just get the "best value" for given state, not caring if it's something default-constructed or actually picked from an event. | 12:23:35 |
| kitsune | So to answer you question directly - the type will be Quotient::Membership, defaulting to Membership::Invalid (aka Membership::Undefined). | 12:25:14 |
| Tobias Fella | so the new version would still have default-generated states/events? isn't that what it's trying to get rid of? | 12:26:33 |
| kitsune | A stricter way could probably recreate the value_or pattern from std::optional where the fallback value is simply passed to the function. | 12:26:35 |
| kitsune | It won't default-construct events anymore. It will default-construct what you're retrieving from it. Which almost always will be some basic thing like int, bool, or QString. | 12:27:24 |
| Tobias Fella | aah, i see | 12:28:00 |
| kitsune | But yes, I'm generally wary of default-constructed values because sometimes they may yield unexpected results (you don't always want to fallback to false in case of boolean values, e.g.). | 12:28:41 |
| Tobias Fella | In reply to @kitsune:matrix.org
A stricter way could probably recreate the value_or pattern from std::optional where the fallback value is simply passed to the function. that would make sense | 12:29:13 |
| Tobias Fella | makes sense overall, but the API is a bit unexpected IMO | 12:31:18 |
| Tobias Fella | but that's not too bad considering that a lot of it is wrapped in convenience functions already | 12:32:05 |
| kitsune | On fallback values, two approaches are possible. The softer one follows Qt conventions: if you don't pass the fallback value, a default-constructed one is used. See QHash::value, e.g. The stricter one is how std::optional does it: you must pass the fallback value, or, if you made sure you're safe, just plain request the value or face an exception/abort etc. | 12:33:16 |
| kitsune | Yes, convenience functions will keep coming. | 12:33:33 |
| kitsune | Because this thing is not accessible from QML anyway. Even the original getCurrentState wasn't, in fact. | 12:34:04 |
| kitsune | And I tend to choose the softer approach because most of the time the default-constructed value is actually fine... | 12:46:45 |
 deltanedas | is there a way to check a user's power level in a room? | 17:22:02 |
| deltanedas | cant find anything in user/room.h | 17:22:23 |
 morguldir | deltanedas: Room::getCurrentState<RoomPowerLevelsEvent>()->powerLevelForUser(user->id()) i think | 18:30:38 |
| morguldir | * deltanedas: Room::getCurrentState<RoomPowerLevelsEvent>()->powerLevelForUser(user->id()) i think | 18:33:04 |
| deltanedas | i assume to set a power level i have to create a RoomPowerLevelsEvent manually too | 19:08:05 |
 Github [@kitsune:matrix.org] | [quotient-im/Quaternion] KitsuneRal closed pull request #812: feat: attach file by inserting(pasting/dropping) it into chatedit [closed] - https://github.com/quotient-im/Quaternion/pull/812 | 20:57:48 |
| 30 Nov 2021 |
|  erik (old) changed their display name from erik to erik (old). | 01:11:19 |
| Tobias Fella | neochat connects to Room::notificationCountChanged to send notifications for new messages, which broke with the recent changes to read marker stuff - is that expected or a regression? | 15:44:20 |
