-
Notifications
You must be signed in to change notification settings - Fork 161
Consistently set defaults for new
-based constructors
#624
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
Comments
This is intentional. The intended way to use it is as follows: new MutationObserverInit {
childList = someChildList
} |
Ahh, indeed! My bad! Feeling kinda stupid now =) |
I think this was what had thrown me off: // Before (deprecated)
val response = dom.experimental.ResponseInit(myStatus, myStatusText, myHeaders)
// After
val response = new dom.ResponseInit {
var status = myStatus
var statusText = myStatusText
var headers = myHeaders
} |
Hmm, is the use of var not needed there? I grabbed that example from one of my own projects: Update: I tried removing it, but it didn't compile, so idk 🙃 |
@armanbilge Here's how I understand it :)
trait ResponseInit extends js.Object {
var status: Int
var statusText: ByteString
var headers: HeadersInit
} and this compiles (overriding-implementing the vars from the trait): val response = new org.scalajs.dom.ResponseInit {
var status = 200
var statusText = "OK"
var headers = scala.scalajs.js.Dictionary.empty[String]
} without putting By contrast, trait MutationObserverInit extends js.Object {
var childList: js.UndefOr[Boolean] = js.undefined
... and scalac won't allow overriding them (vars) – I think this was the first time I ever tried to override a var – so the way to initialize them is as Sébastien suggested: by creating a new instance (with default initial values for those vars) and then imperatively re-assigning those vars in the constructor: new MutationObserverInit {
this.childList = somChildList
} The benefit of it is we don't have to specify(implement) all the vars, only those that we care about. |
Aha, excellent clarification! Thank you. Seems like we need to be more consistent with this? I.e. |
new
-based constructors
Consistency would be nice! But I can see why we have it done this way: for a |
I thought the same, so I checked MDN and in fact their example omits the https://developer.mozilla.org/en-US/docs/Web/API/Response/Response#examples Given that this inconsistency can be confusing/surprising, I think we should change this. Also, not necessarily all fields have to default to |
Indeed. Interesting 🤔. Well, I'm really not sure what the best way to approach this is. A change like this would be a breaking change, at the very least. |
Source breaking but not binary-incompatible, so if we decide to go forward with it, it can land in 2.1.0. |
MutationObserverInit
is defined as a trait with vars and initial values, thus doing this won't compile:As a slight inconvenience, because the fields are initialized in the trait, the
override
modifier is required.But what doesn't work is overriding the vars:
scalac
complainsmutable variable cannot be overridden
.The text was updated successfully, but these errors were encountered: