Zicklag
Zicklag
I was kind of interested in this too, just out of curiosity. What would be the purpose of a varlink "device"? --- @i-rinat As far as being able to transfer...
I did this super simply like this: ``` #let fa(codepoint) = text(font: "FontAwesome", codepoint) #let fa-github = fa("\u{f09b}") #let fa-envelope = fa("\u{f0e0}") #let fa-map-marker = fa("\u{f041}") #let fa-suitcase = fa("\u{f0f2}")...
Relevant to this discussion is #142. In order to have dynamically registered components, `TypeId` would need to become more of a `ComponentId` and would have to be suitable for components...
I opened a forum topic to find out if there is a way, without using specialization, to automatically implement a `Component` trait using the `TypeId` approach ( which I think...
Oh, OK. That works. :smile: :+1: I think that's easy, then. What do you think of renaming it `ComponentId`? That is what it is really for right? To uniquely identify...
> So btw, using the cargo metadata will require a procedural macro (since env::var is not a const fn). Actually we can just use the `env!()` macro which grabs environment...
Oh, well, unfortunately, `type_name()` is not stable as a `const fn` yet, it's an unstable nightly feature, which throws a wrench in the whole compile time type name hashing idea....
Yeah, I'm thinking that to get all the features we want we are just going to need to require a `#[derive(Component)]` for all components. It's kind of nice for demos,...
> Imo if rust paths are suitable for importing types in the rust language (and trusting that those imports are what we want them to be), then they should be...
OK, trying to think about every kind of option we have, it looks ( somewhat obviously ) like there are two realms of possibility, compile time and runtime `TypeID` generation....