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.

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

how can i identify a struct, and whether it's shared? #23

Closed
ljharb opened this issue Apr 11, 2024 · 5 comments
Closed

how can i identify a struct, and whether it's shared? #23

ljharb opened this issue Apr 11, 2024 · 5 comments

Comments

@ljharb
Copy link
Member

ljharb commented Apr 11, 2024

My understanding is that a struct is just a sealed object with null, or another struct, as a [[Prototype]] (shared structs may have an object with methods as their [[Prototype]]).

Given some x, how can i determine if it's an unshared struct, or a shared struct, vs a non-struct?

@syg
Copy link
Collaborator

syg commented Apr 11, 2024

Because [[Prototype]] chains are immutable for both unshared and shared structs, you should use instanceof for checking instances of specific classes.

For unshared structs, there's nothing really distinguishing it from a sealed object with non-generic methods.

For shared structs, it might be worth adding a brand check, or at least a general isShared predicate to check for things being shared and therefore have the "can't point to unshared things" restriction.

What's the use case?

@ljharb
Copy link
Member Author

ljharb commented Apr 11, 2024

Debugging, logging, test frameworks - anything where a value needs to be described in a robust way.

For unshared structs, is there any special behavior they have, or is it literally just syntax sugar for something else? Can I perfectly replicate an unshared struct without the syntax?

A predicate would be perfectly fine, for either/both.

@syg
Copy link
Collaborator

syg commented Apr 11, 2024

Debugging, logging, test frameworks - anything where a value needs to be described in a robust way.

But what's the use case for debugging, logging, and testing unshared structs differently than sealed objects? I can see the need to do it for shared structs, but there I see it as a need for all shared objects.

For unshared structs, is there any special behavior they have, or is it literally just syntax sugar for something else? Can I perfectly replicate an unshared struct without the syntax?

You'd have to write some custom constructors but yes.

@ljharb
Copy link
Member Author

ljharb commented Apr 11, 2024

In that case I'd only require a predicate for shared ones, even though it'd still be nice for an unshared one. I totally agree that it applies to all shared objects, but in order to have the ability to help the user find the thing in question in their code, i'd still need to know that it's a shared struct, specifically.

@syg
Copy link
Collaborator

syg commented Sep 30, 2024

Considering this issue addressed. To recap:

  • For unshared structs, there's no brand check as they are "just" sealed ordinary objects. Since struct instance methods are non-generic, all struct instance methods may be considered brand checks for instances of that particular struct.

  • For shared structs, the spec draft includes a Reflect.canBeShared, which returns true for shared structs and primitives. This can be used in conjunction with typeof foo == 'object' to see if something is a shared struct in particular.

@syg syg closed this as completed Sep 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants