Giter Club home page Giter Club logo

Comments (5)

linabutler avatar linabutler commented on August 18, 2024

I guess approach four is, do nothing, and let authors figure it out when they get a compile error. While I think we could be a little more helpful (it’s not immediately obvious to make the connection from an error in codegen to “oh, right, I can’t name this argument func in Swift” or “hmmm, it doesn’t like my Lowerable type, I guess there’s already a helper that defines one”), our target languages do have good compiler errors.

from uniffi-rs.

thomcc avatar thomcc commented on August 18, 2024

Approach 1 seems totally fine to me. Its not like these names are very likely to cause collisions, but it would be good to give good error messages in the very unlikely case that collisions happen.

I think if it could piggyback off of whatever approach is used to complain about using other reserved words that would be good.

prefix or suffix internal stuff (and reserved words!) with _

Note that if we do this for C it's a problem, all symbols beginning with _ in the global namespace are reserved IIRC (and all symbols that are _ followed by a capital in any namespace, including local vars, are reserved).

That said suffix is probably fine so long as it doesn't have __, which is also reserved in all namespaces.

from uniffi-rs.

thomcc avatar thomcc commented on August 18, 2024

That said suffix is probably fine so long as it doesn't have __, which is also reserved in all namespaces.

It occurs to me that we should probably error for this too if a user symbol in rust has it after our transformations. I'd rather not invent our own mangling scheme to solve these (although in principal it would probably work), so I think we'll probably need a function that validates that an identifier is valid to expose.

from uniffi-rs.

rfk avatar rfk commented on August 18, 2024

I think if it could piggyback off of whatever approach is used to complain about using other reserved words that would be good.

Such a thing doesn't really exist yet, but 100% should and definitely sounds like the right place to do these checks..!

from uniffi-rs.

rfk avatar rfk commented on August 18, 2024

Approach 3.1: prefix or suffix internal stuff (and reserved words!) with _. Also easy, and probably good enough!

In my head, I think I was more-or-less intending to take this approach, but @thomcc raises a good point about it conflicting with other naming conventions.

Another option I was thinking about, which makes more sense in some target languages than others, was to actually move all of those helpers out of the public classes themselves. Strawman: if we expose a record name Point as a class, then the only methods on that class are the ones defined by the component. Internally, we have a separate helper class named _Uniffi_PointRecord on which we define the helpers like lift, lower, etc. Instead of calling p.lower(), the generated code would call _Uniffi_PointRecord.lower(p).

This would keep the exported namespaces nice and clean, but might make the generated code much messier and harder to debug. It might also show up as visible artifacts when using the public interface, such as confusing lines in your tracebacks.

Starting with Approach One (the blanket ban) seems like the right move I think, since it's easier to loosen restrictions in future then to tighten them.

Unconditionally append a random, short ID to internal symbols. [...] though we can make the scheme predictable—again,
borrowing from how name mangling works in other languages).

Unrelated to the public API surface, I was wondering whether we should try something like this as a safety measure for the extern C layer:

  • Predictably generate a "tag" for every item in the FFI layer, perhaps as a hash of its components in the IDL. It would be important for this value to be a deterministic function of the IDL.
  • Append this tag to all symbols exported from the dylib, so that e.g. the fxa_new function becomes fxa_new_1234.
  • Have both sides of the FFI expect to find the exported symbols under their tagged names.

That's a bit of extra complexity in the generated bindings, but it would help prevent accidentally using the Kotlin bindings from version X or a component with the dylib from version Y; it wouldn't even be able to load the dylib successfully because all the symbol names would be different!

from uniffi-rs.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.