New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add backend parameters to native annotation #252
Comments
This will enabled us to properly process |
How is that related to I would agree that it could be useful. I would make the list of backends an enum, but because we don't have real enums in the JVM sense, I don't think we can use enum values as annotation parameters ATM. @tombentley can confirm/deny. As far as the JVM backend is concerned those native annotations are ignored anyways ATM. |
what? you ignore native as well? then WTF do we even have it for? Regarding Maybe it's two separate things and the nativejs annotation will remain, but I believe we definitely should add the backend(s) to the |
Well, I guess we should not ignore it, but build support for it. ATM it's only used by the language module and we do not include the bits with |
The native annotation is supposed to let you write a class in Ceylon and have, for example, just one method implemented in Java + JavaScript. But that's not supported yet, and we have not yet defined what that would look like from the java/js side. Sent from my iPhone On 10/07/2013, at 6:19 PM, Stéphane Épardaud notifications@github.com wrote:
|
@chochos Are you sure there are things marked We did have some examples of backend-specific native code before, but that was when the JVM compiler had some restrictions. Do we still have those problems now? (And if we can only come up with one or two simple cases is it worth the trouble?) And |
So then you can use nativejs to make something a Ceylon class even though it doesn't conform to the mappings of Ceylon to JS or even know it's own type?! Doesn't that mean it breaks as soon as you assign an instance to Object? Sent from my iPhone On 10/07/2013, at 6:40 PM, Tako Schotanus notifications@github.com wrote:
|
I knew it would have enough information to know its own type, but now looking at the code in the web backend I see that at a later date even meta model information was added. I didn't implement that so I'm not sure how much it supports, I think @chochos or @ikasiuk will be able to give more details. |
How does that work, precisely? |
As far as I can remember + what I can deduce from the code is that we extend the JS type with the information required by Ceylon. So we take an existing JS type and add onto it the information we supply with Ceylon interfaces marked "nativejs". For example, the native toplevel attribute The advantage of this method is that a) we have type safety and b) it works in cases where wrappers wouldn't (for example in the case of the DOM tree it's the browser that's in control of creating / deleting most of the tree elements). The disadvantage is (right now at least) that it's a lot of manual work. |
@quintesse |
@chochos true, but that's also an example of a very trivial class, I'm wondering if there's anything that has a bit more "meat" to it. Just to see if it's worth the trouble. |
Right now the JVM compiler doesn't support this, but it will once I add the extra transformation which handles all these funky cases. It makes me wonder how we will document it though, since the |
We could just use strings then, as long as we properly document what the valid backends are it shouldn't be a big problem. Right now we're only using it in the language module but it could be used in other modules as well. I'm thinking of a way to make it more useful for js, but I think I'll elaborate on that repo, not here. |
The
native
annotation is incomplete; there is a lot of stuff in the language module annotatednative
which can be compiled to js, so it's really only annotated for the jvm compiler.So the annotation should have a parameter which is the list of backends that the declaration is native for; no args means it's native for all backends.
Question is: should the backends be objects, or simply strings?
i.e.
we can define a Backend or Platform class with two cases, jvm and javascript. It can even be used in the
process
object, which I think already has a platform property.The text was updated successfully, but these errors were encountered: