I guess I should have specified that I meant getting the attributes from a type. That doesn't work? AFAIK that's not part of reflection TS.
-
-
Vastauksena käyttäjälle @seanbax
ah, yeah, the TS in its current state does not handle attributes, but they are working on it.
@Cor3ntin and@hankadusikova would give better info than me on this.1 vastaus 0 uudelleentwiittausta 0 tykkäystä -
Vastauksena käyttäjille @Manu343726, @seanbax ja2 vastausta 0 uudelleentwiittausta 0 tykkäystä
-
Vastauksena käyttäjille @Manu343726, @seanbax ja
(it proposes exposing attributes as classes, the thing that spawned this thread)
1 vastaus 0 uudelleentwiittausta 0 tykkäystä -
Better to separate attribute names from types. If you want multiple point2 attributes, are you supposed to keep coining new point2-like structs? I put in attribute names as special types for this reason: using L1 [[attribute]] = point2; using L2 [[attribute]] = point2; etc
2 vastausta 0 uudelleentwiittausta 0 tykkäystä -
Vastauksena käyttäjille @seanbax, @Manu343726 ja
I disagree, I want strong typing on my _consumption_ of attributes, e.g. being able to dispatch attribute handling via function overloads or template specialization. Adding another "attribute name" entity that doesn't participate in the type system is not what I want.
2 vastausta 0 uudelleentwiittausta 0 tykkäystä -
Vastauksena käyttäjille @seanmiddleditch, @seanbax ja
I think some of your points stand about duplication, but I see that as orthogonal. We've wanted "opaque typedefs" in C++ for years; instead of an attribute-specific solve, I'd rather we keep attributes simple and extend C++ elsewhere to since the whole group of related issues.
1 vastaus 0 uudelleentwiittausta 0 tykkäystä -
Vastauksena käyttäjille @seanmiddleditch, @stmiddleditch ja
What are the other users of opaque typedefs? I'd remove the attribute names and use those instead if there was another use case.
1 vastaus 0 uudelleentwiittausta 0 tykkäystä -
Vastauksena käyttäjille @seanbax, @stmiddleditch ja
I always come up with the same example: Database IDs using UserId = int; using BookId = int;
2 vastausta 0 uudelleentwiittausta 0 tykkäystä -
Vastauksena käyttäjille @Manu343726, @seanbax ja
you don't want those two to be interoperable in any way, it always leads to hard to debug issues. But at the same time, both are just ints in the DB engine
2 vastausta 0 uudelleentwiittausta 1 tykkäys
enum struct BookId : int {}; Then a convenience function that helps covert it to int when needed, by using std::underlying_type. Template it so you can use it everywhere.
-
-
Wow I think I never used enum struct before xD. enum class a million times, but never as enum struct
1 vastaus 0 uudelleentwiittausta 0 tykkäystä -
Vastauksena käyttäjille @Manu343726, @seanbax ja
There is an argument that because an enum’s static members are public, it is weird to call it a class.
0 vastausta 0 uudelleentwiittausta 2 tykkäystä
Keskustelun loppu
Uusi keskustelu -
Lataaminen näyttää kestävän hetken.
Twitter saattaa olla ruuhkautunut tai ongelma on muuten hetkellinen. Yritä uudelleen tai käy Twitterin tilasivulla saadaksesi lisätietoja.