Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Support returning objects from functions and methods #197

Closed
jhugman opened this issue Aug 3, 2020 · 3 comments
Closed

Support returning objects from functions and methods #197

jhugman opened this issue Aug 3, 2020 · 3 comments

Comments

@jhugman
Copy link
Contributor

jhugman commented Aug 3, 2020 •
edited by data-sync-user
Loading

As part of #37 and complementing #40. Putting this here so it doesn't get lost.

We should be able to return objects from functions and methods:

e.g.

val pool = new ThingPool()
val thing = pool.getOrCreate(id = "abc")

// later on 
val sameThing = pool.getOrCreate(id = "abc")

// The objects are equal.
assert(thing == sameThing)

// The objects are the same.
// it might be ok if this isn't true, but we need to discover the assumptions and document them.
assert(thing === sameThing)

The === case is the hard bit! We could maintain a handle_map on the platform side, but then we have some book keeping to do around destruction, including if the object is destructed on the Rust side. If the objects must be the same, then we should do it in a separate issue.

┆Issue is synchronized with this Jira Task
@jhugman jhugman added the discuss label Aug 3, 2020
@jhugman jhugman mentioned this issue Nov 6, 2020
Merged
@rfk rfk mentioned this issue Jan 14, 2021
Closed
@rfk
Copy link
Collaborator

rfk commented Jan 14, 2021

Ref #366 (comment) for a concrete use-case for this.

@rfk
Copy link
Collaborator

rfk commented Jan 14, 2021

Since this was on my radar, a bit of a brain-dump of another possible source of complexity here...

When returning an object from a Rust function, how do we know whether this was an object that was already in the handlemap, or whether it needs to be added to the handlemap? If it's an existing instance, how do we discover its existing handle in order to return that value across the FFI? I feel like we may have to expose some of the internal details of how the handlemap works so that the hand-written Rust code for the component can cooperate with the generated Rust scaffolding in order to make this work.

rfk added a commit that referenced this issue Feb 15, 2021
@rfk
Add support for factory functions and static methods.
f291b2a 
It's a fairly common pattern for object-oriented interfaces to have
named functions or static methods that act as named "factories" for
producing object instances in ways that differ from the default
constructor. This commit adds basic support for such factories
by:

* Allowing owned object instances to be returned from functions
  and methods.
* Allowing interface methods to be marked as `static`.

The "owned object instances" part here is really key, since it
allows us to bypass a lot of the general concerns about returning
*references* to object instances that are outlined in #197 (and
that this commit does not at all attempt to tackle).
rfk added a commit that referenced this issue Feb 15, 2021
@rfk
Add support for factory functions and static methods.
b2c29c2 
It's a fairly common pattern for object-oriented interfaces to have
named functions or static methods that act as named "factories" for
producing object instances in ways that differ from the default
constructor. This commit adds basic support for such factories
by:

* Allowing owned object instances to be returned from functions
  and methods.
* Allowing interface methods to be marked as `static`.

The "owned object instances" part here is really key, since it
allows us to bypass a lot of the general concerns about returning
*references* to object instances that are outlined in #197 (and
that this commit does not at all attempt to tackle).
rfk added a commit that referenced this issue Feb 15, 2021
@rfk
Add support for factory functions and static methods.
3421419 
It's a fairly common pattern for object-oriented interfaces to have
named functions or static methods that act as named "factories" for
producing object instances in ways that differ from the default
constructor. This commit adds basic support for such factories
by:

* Allowing owned object instances to be returned from functions
  and methods.
* Allowing interface methods to be marked as `static`.

The "owned object instances" part here is really key, since it
allows us to bypass a lot of the general concerns about returning
*references* to object instances that are outlined in #197 (and
that this commit does not at all attempt to tackle).
rfk added a commit that referenced this issue Feb 15, 2021
@rfk
Add support for factory functions and static methods.
0c1a59d 
It's a fairly common pattern for object-oriented interfaces to have
named functions or static methods that act as named "factories" for
producing object instances in ways that differ from the default
constructor. This commit adds basic support for such factories
by:

* Allowing owned object instances to be returned from functions
  and methods.
* Allowing interface methods to be marked as `static`.

The "owned object instances" part here is really key, since it
allows us to bypass a lot of the general concerns about returning
*references* to object instances that are outlined in #197 (and
that this commit does not at all attempt to tackle).
@rfk rfk mentioned this issue Feb 15, 2021
Closed
rfk added a commit that referenced this issue Feb 15, 2021
@rfk
Add support for factory functions and static methods.
dff6553 
It's a fairly common pattern for object-oriented interfaces to have
named functions or static methods that act as named "factories" for
producing object instances in ways that differ from the default
constructor. This commit adds basic support for such factories
by:

* Allowing owned object instances to be returned from functions
  and methods.
* Allowing interface methods to be marked as `static`.

The "owned object instances" part here is really key, since it
allows us to bypass a lot of the general concerns about returning
*references* to object instances that are outlined in #197 (and
that this commit does not at all attempt to tackle).
rfk added a commit that referenced this issue Feb 15, 2021
@rfk
Add support for factory functions and static methods.
af1d8a9 
It's a fairly common pattern for object-oriented interfaces to have
named functions or static methods that act as named "factories" for
producing object instances in ways that differ from the default
constructor. This commit adds basic support for such factories
by:

* Allowing owned object instances to be returned from functions
  and methods.
* Allowing interface methods to be marked as `static`.

The "owned object instances" part here is really key, since it
allows us to bypass a lot of the general concerns about returning
*references* to object instances that are outlined in #197 (and
that this commit does not at all attempt to tackle).
rfk added a commit that referenced this issue Feb 15, 2021
@rfk
Add support for factory functions and static methods.
751a7d4 
It's a fairly common pattern for object-oriented interfaces to have
named functions or static methods that act as named "factories" for
producing object instances in ways that differ from the default
constructor. This commit adds basic support for such factories
by:

* Allowing owned object instances to be returned from functions
  and methods.
* Allowing interface methods to be marked as `static`.

The "owned object instances" part here is really key, since it
allows us to bypass a lot of the general concerns about returning
*references* to object instances that are outlined in #197 (and
that this commit does not at all attempt to tackle).
@rfk rfk mentioned this issue Mar 17, 2021
Closed
@rfk
Copy link
Collaborator

rfk commented Jun 14, 2021

This is now possible as of v0.12.0.

@rfk rfk closed this as completed Jun 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@rfk @jhugman @data-sync-user