In case its not clear from the minutes, we didn’t cover anywhere near everything and will continue next week. In particular we didn’t make any of the hard decisions, never mind deciding on what should actually get added to the language.
The recent activities make me feel that we are going to do inheritance pre-1.0, but I suppose the plan was to do it post-1.0? Or are we merely outlining a plan but will delay the actual implementation?
The idea is that we just want a plan pre-1.0. The bulk of implementation work will be post-1.0. But we want to make sure that everything is backwards compatible, so some work might have to happen pre to avoid backwards compatibility hazards.
Having said that, this is very high priority for Servo, so that is probably enough reason to start implementation early if there are not higher priority things to work on.
Re the “initial call is virtual, all further are statically dispatched” part about #250: I actually discovered that this is avoidable (eg, can be made statically), by directly implementing on the unsized trait object instead of making it a associated method.
I wrote a comment under #250 explaining it a bit more in detail
I notice there was agreement that inheritance should be ergonomic and “native”, not deliberately obtuse to discourage its use - fair enough, but please provide guidelines to library authors on whether it ought to be used in public API. There seem to be two schools of thought:
-
Servo is the motivating example for Rust, a realworld(ish) application, and this abstraction needed by real applications should not be “punished” when used, v.s.
-
The DOM is a badly designed legacy which requires an unusual combination of optimisations; the language should be able to support this, being after all low level, but future software has no need for it.
Whichever horse you want to back, it would be best to have a clear decision.
@gulbanana, I believe, if the syntax gets too lightweight, then no guideline can stop people from overusing DOM style inheritance. (If we do want to stop this, that is.)
No matter which school of thought one picks, the main problem with “native” DOM style inheritance is that, it is a specific style of inheritance, with specific layouts, optimizations and limitations. It is possible that we’ll want more flexibility (like for interop purposes). If so, I believe the solution is “default to flexibility, with the ability to opt-in to optimizations/interop support ergonomically”.
“Default to DOM style, with the ability to opt-in to flexibility and interop” may also work. But personally I still prefer “flexibility first”.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.