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

should provide advice on when it's good to return the same object again #46

Closed
dbaron opened this issue Feb 11, 2017 · 9 comments
Closed
Assignees
Projects

Comments

@dbaron
Copy link
Member

dbaron commented Feb 11, 2017

As a followup to #34 (which I will make a pull request for shortly), I think the document should provide advice on when it's acceptable / good for an API to return the same object repeatedly, versus when it should return a new object each time. This advice presumably differs for methods versus attribute getters (since there are cases when attributes are required to return the same object), and also for live versus static objects (since live objects allow more flexibility to return the same object).

The section addressing this should probably be near the section added by #34.

@domenic
Copy link
Member

domenic commented Feb 11, 2017

Related, but not necessarily redundant: https://w3ctag.github.io/design-principles/#attributes-like-data

@dbaron
Copy link
Member Author

dbaron commented Jul 26, 2017

From TAG discussion today: perhaps the methods versus attributes thing is even the other way around: if you're returning the same object again, you should have an attribute; if you're always creating a new object, you should have a method.

@torgo torgo added the Status: In Progress We're working on it but ideas not fully formed yet. label Jul 26, 2017
@torgo torgo added Status: Consensus to write We have TAG consensus about the principle but someone needs to write it (see "To Write" project) and removed Status: In Progress We're working on it but ideas not fully formed yet. labels Apr 6, 2018
@torgo
Copy link
Member

torgo commented Apr 6, 2018

@dbaron to write some text.

@dbaron
Copy link
Member Author

dbaron commented May 27, 2020

@cynthia and I just discussed this a little bit in a breakout.

I think the most normal cases are:

  • function or attribute getter returns live object, and it's the same object each time
  • function return static object/state, and it's a new object each time

I believe there are a bunch of exceptions to this on the web platform, but we didn't get to the point of trying to make a list of them. I think the interesting question about these exceptions is: are any of them good? If so, why?

I think if we can answer that, we can probably provide useful advice here.

@annevk
Copy link
Member

annevk commented May 28, 2020

I think there's at least one other case, very common in node trees:

  • method or getter from an object A returns an object from an internal slot and that internal slot can be manipulated, potentially causing another things to be returned when it is manipulated. (E.g., firstChild.)

@dbaron
Copy link
Member Author

dbaron commented Sep 25, 2020

I think the case @annevk mentions in #46 (comment) is probably not a separate case, but rather digging into the subtlety about what we mean by "the same object each time". In other words, things where we're saying the normal thing is "return the same object each time" don't necessarily return the same object all the time; for many such cases there are state changes that cause the object it returns to change. (But there are also a bunch where there are no such state changes.)

On the other hand, maybe it is worth describing those as separate cases, but I wasn't really thinking of them as such.

@dbaron
Copy link
Member Author

dbaron commented Sep 25, 2020

@cynthia is likely going to try to address both this and #70 in the same PR.

@annevk
Copy link
Member

annevk commented Sep 25, 2020

@dbaron that's fair. When I read "same object each time" I see [SameObject] (which one day will be made useful and renamed to [Cached]). And given that terminology from IDL you probably do want to be explicit about it.

@torgo torgo added the Overtaken? This is an old issue that may no longer be relevant? label May 3, 2021
@LeaVerou LeaVerou added this to Unassigned in To Write Sep 16, 2021
@LeaVerou LeaVerou moved this from Unassigned to cynthia in To Write Sep 16, 2021
@plinss plinss added this to the 2022-01-17-week milestone Jan 13, 2022
@cynthia cynthia removed Status: Consensus to write We have TAG consensus about the principle but someone needs to write it (see "To Write" project) Overtaken? This is an old issue that may no longer be relevant? labels Mar 22, 2022
@cynthia
Copy link
Member

cynthia commented Mar 22, 2022

This was addressed in #70, but never closed.

@cynthia cynthia closed this as completed Mar 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
To Write
cynthia
Development

No branches or pull requests

6 participants