Awesome
Awesome
PostsComments
LTLeaning Technologies
Created by Awesome on 5/11/2024 in #support
Compatibility with the typeof, instanceof keywords
Okay, got it, yes that's fine, good to know, it would be nice to have it as it comes in pretty handy when dealing with weakly typed parameters. Besides that I'll probably wait till the next stable release anyway.
12 replies
LTLeaning Technologies
Created by Awesome on 5/11/2024 in #support
Compatibility with the typeof, instanceof keywords
Personally I feel like leaving for it a dedicated templated intrinsic would be pretty acceptable, like for example client::instanceof<T>()/cheerp::instanceof<T>()?
12 replies
LTLeaning Technologies
Created by Awesome on 5/11/2024 in #support
Compatibility with the typeof, instanceof keywords
I'm not sure if having it as a part of an object would be a good idea, mixing JS object's methods with Cheerp's ones feels a bit questionable
12 replies
LTLeaning Technologies
Created by Awesome on 5/11/2024 in #support
Compatibility with the typeof, instanceof keywords
Sure, I wasn't exactly talking about extending it with a new keyword as it would likely break the compatibility with C++ but more of an adding a support at a compiler intrinsics level, which would allow the types to be passed as actual values via the template, the asm, as I said before is quite limited in regards to passing those 
__asm__("%1 instanceof %2" :"=r"(result): "r"(object), "r"(client::Array)); // in C++ types are not allowed to be passed as runtime values, resulting in an invalid code
__asm__("%1 instanceof %2" :"=r"(result): "r"(object), "r"(client::Array)); // in C++ types are not allowed to be passed as runtime values, resulting in an invalid code
12 replies
LTLeaning Technologies
Created by Awesome on 4/12/2024 in #support
WASM-less compiling
Ahh, okay, my bad, the toolchain I tested on used CheerpWASMToolchain.cmake instead of CheerpToolchain.cmake which resulted in ignoring the set cheerp's target, which made me also think that it's not working, now while I tested it on the actual one everything works as it should
4 replies
LTLeaning Technologies
Created by Awesome on 4/2/2024 in #support
Runtime class extending
I'll probably gonna be better off with this for now then, it's a bit tedious to do it that way but it's better than nothing 😃
17 replies
LTLeaning Technologies
Created by Awesome on 4/2/2024 in #support
Runtime class extending
Alright, got it
17 replies
LTLeaning Technologies
Created by Awesome on 4/2/2024 in #support
Runtime class extending
Ahh, okay, I see 😕
17 replies
LTLeaning Technologies
Created by Awesome on 4/2/2024 in #support
Runtime class extending
I think it could be marked as something that is "off to the browser" and compiler shouldn't really care much about the base object other than checking the interface's typings
17 replies
LTLeaning Technologies
Created by Awesome on 4/2/2024 in #support
Runtime class extending
Hmmm, yeah, I get that, wouldn't it be quite alike to handling those objects as the other client::* native objects are being handled?
17 replies
LTLeaning Technologies
Created by Awesome on 4/2/2024 in #support
Runtime class extending
In fact I feel like this could be implemented and would be in some cases useful considering it wouldn't be falling much outside of the scope of what really Cheerp tries to go towards to - "... expressive intefacing with JavaScript libraries and the DOM, without wrappers or any overhead". 😃
17 replies
LTLeaning Technologies
Created by Awesome on 4/2/2024 in #support
Runtime class extending
Couldn't it be still handled by the compiler? Like when it sees that the class has let's say an attribute [[cheerp::extendsjs]] attached to it, it could just put the ES6 extends AST part based on the parent's interface namespace path (like it's being resolved right now but with extends keyword), later on the ExtendedClass would let know that it should call parent's constructor aka super(...) based on the constructors chain, or when in case ES6 isn't possible to be used, provide an ES5 abstraction on top of it (setPrototypeOf() with apply()).
17 replies
LTLeaning Technologies
Created by Awesome on 4/2/2024 in #support
Runtime class extending
Ohh, okay, just wanted to ensure that I didn't miss out anything, my goal was to actually provide an interface for a library and extend its class as an actual Cheerp's code - which is somewhat required in my case mostly because of how the library manages the provided objects, it seemed to be quite logical to me that it would work, as Cheerp appears to have mostly all the necessary information about the objects it works on. Ideally, I would avoid dealing with raw JS or its imports on the Cheerp side but I guess it's currently the only way for now.
17 replies
LTLeaning Technologies
Created by Awesome on 4/2/2024 in #support
Runtime class extending
As this approach seems to fail 
namespace [[cheerp::client_layout]] client::ExampleLibrary {
    struct BaseClass {};
}

struct [[cheerp::genericjs]] ExtendedClass: public client::ExampleLibrary::BaseClass {} 

[[cheerp::genericjs]] void webMain() {
    auto example = ExtendedClass();
}
namespace [[cheerp::client_layout]] client::ExampleLibrary {
    struct BaseClass {};
}

struct [[cheerp::genericjs]] ExtendedClass: public client::ExampleLibrary::BaseClass {} 

[[cheerp::genericjs]] void webMain() {
    auto example = ExtendedClass();
}
- TypeError: g.BaseClass is not a function
- TypeError: g.BaseClass is not a function
17 replies
LTLeaning Technologies
Created by Awesome on 2/25/2024 in #support
State of the C++ modules support
Okay, got it, I think it covers my question, thanks!
5 replies
LTLeaning Technologies
Created by Awesome on 2/25/2024 in #support
State of the C++ modules support
I was more concerned about C++23, which includes std modules as well, although thanks for letting know! Are there any plans of releasing Cheerp with the newer Clang base in the near future?
5 replies