You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
**Eugene**[YouTube time: 25’30’](https://youtu.be/gnlL4PlstFY?t=1530) thinks that the proposal needs to be cleared about the impact, referring to possible replacements with string literals that might never happen. Suggests to position this proposal as simply removing the feature and leaving it up to the community to decide and implement the replacements (?)
210
+
**Eugene** ([YouTube time: 25’30’](https://youtu.be/gnlL4PlstFY?t=1530)) thinks that the proposal needs to be cleared about the impact, referring to possible replacements with string literals that might never happen. Suggests to position this proposal as simply removing the feature and leaving it up to the community to decide and implement the replacements.
211
+
211
212
**Martin**https://youtu.be/gnlL4PlstFY?t=1579 responds by saying Committee should be responsible because…
212
-
**Josh** 27’16’’ https://youtu.be/gnlL4PlstFY?t=1636 clarifies that in order to replace the libraries (XML with string literals) one would need a proof, and currently there is none.
213
+
**Josh** 27’16’’ https://youtu.be/gnlL4PlstFY?t=1636 clarifies that in order to replace the libraries (XML with string literals) one would need a proof of concept, and currently there is none.
213
214
215
+
**Adriaan**[YouTube time 30’](https://youtu.be/gnlL4PlstFY?t=1796) summarises the discussion, pointing out that Committee needs to answer a question "will we support XML in some way" and "waht would be the most "Scala-like" way to do so and who will be maintaing it.
214
216
215
-
…. Not understanding
216
-
**Jorge**[Youtube time 28.53](https://youtu.be/gnlL4PlstFY?t=1732) asks what does Committee think about the counter proposal?
217
-
**Adriaan** summarises at [YouTube time 30’[(https://youtu.be/gnlL4PlstFY?t=1796)
218
-
Again not really clear until 34.30 Iulian
219
-
Seb answers a youtube comment
220
217
**Seth**[YouTube time 35’57’’](https://youtu.be/gnlL4PlstFY?t=2157) is under the impression that large portion of XML user base are the ones using it to do generation and rarer to be reading in XML using the existing Scala XML support and asks others to share their impressions.
221
218
**Martin** re-phrases it as “using XML for pattern matching”.
222
219
**Sébastien** says it is super rare.
223
220
**Iulian** says it is used more than we think in pattern matching and in value definitions he seen in not OS projects; they can be found in old, large code basis; probably decreasing.
224
221
He suggests to ask IntelliJ to collect and share the XML usage patterns.
225
222
226
-
**Conclusion** ???
227
-
[“Proposal to remove the procedure Syntax”](https://contributors.scala-lang.org/t/proposal-to-remove-procedure-syntax/2143)
223
+
### [“Proposal to remove the procedure Syntax”](https://contributors.scala-lang.org/t/proposal-to-remove-procedure-syntax/2143)
**Josh Suereth** summarised the discussion on Contributors thread:
230
228
231
-
Underlines the general concern about the lack of motivation part of the proposal;
232
-
Notes that in the Contributors discussion, ones that were for the removal would mostly put “+1” while ones against the removal would be more elaborate, that gives a false impression there were more arguments against the removal;
233
-
Structures his presentation around community’s points in a light of better motivation adding his opinion after each
234
-
Concludes that that going forward procedure syntax should be removed because in the long run it helps new developers learn Scala faster and better (more details below).
229
+
-Underlines the general concern about the lack of motivation part of the proposal;
230
+
-Notes that in the Contributors discussion, ones that were for the removal would mostly put “+1” while ones against the removal would be more elaborate, that gives a false impression there were more arguments against the removal;
231
+
-Structures his presentation around community’s points in a light of better motivation adding his opinion after each
232
+
-Concludes that that going forward procedure syntax should be removed because in the long run it helps new developers learn Scala faster and better (more details below).
235
233
236
234
Summary + **Josh’s** comments:
237
235
238
236
Fixable/Addressable Concerns
239
-
Concerned that rewrite tools (and people) would use def foo() = {} syntax instead of def foo(): Unit = {}
237
+
- Concerned that rewrite tools (and people) would use def foo() = {} syntax instead of def foo(): Unit = {}
238
+
240
239
Pros
241
-
Clean up inconsistency in the language
242
-
Dropping return value is dangerous, in general
240
+
241
+
- Clean up inconsistency in the language
242
+
- Dropping return value is dangerous, in general
243
243
*Experience teaching Scala gave an insight to how often the return value is dropped which leads to broken code leaving students confused*
244
+
244
245
Cons
245
-
More verbose syntax to safely ignore return values
246
+
-More verbose syntax to safely ignore return values
246
247
*Semi legitimate concern; developers need to change their habits and annotate return values when it’s important*
247
-
Lazy people will just write def foo() = {} and get bad behavior.
248
+
-Lazy people will just write def foo() = {} and get bad behavior.
248
249
*The way it is written leads to a confusion and should be removed from the proposal why: https://youtu.be/gnlL4PlstFY?t=2795 *
250
+
249
251
Not well motivated Pros
250
-
Safer
252
+
253
+
- Safer
251
254
*We need to detail “why” it is safer*
252
-
Cleaner for refactoring tools to treat methods of this sort.
255
+
256
+
- Cleaner for refactoring tools to treat methods of this sort.
253
257
*Given the way things are structured, this issue comes down to the way the methods are parsed => change the parser betters the refactoring tools. This point needs to be clear in the proposal*
258
+
254
259
Not well motivated Cons
255
-
People have to change their habits
256
-
Proposal coming from people who don't mutate state
260
+
261
+
- People have to change their habits
262
+
- Proposal coming from people who don't mutate state
257
263
*After analyzing two of his “side-effecty” codebases, looking to find where he uses the most procedure syntaxes, Josh concluded that there are many : Unit*
258
-
Call into question authority/judgement of proposer
264
+
-Call into question authority/judgement of proposer
259
265
*Josh doesn’t find it appropriate and will ignore such comments stating that “...it is not a legitimate way to make a technical argument.” [YouTube time 42’07’’](https://youtu.be/gnlL4PlstFY?t=2522)*
266
+
260
267
Counter Proposals
261
-
Effect tracking
268
+
269
+
- Effect tracking
262
270
*A bit of an “overkill”*
263
-
Multiple "def" keywords, one which would mean side-effecting function
271
+
-Multiple "def" keywords, one which would mean side-effecting function
264
272
:= for side effects
265
273
266
274
**Josh** concludes: big point to debate would the language consistency be worth the change to more verbose expresion.
@@ -270,16 +278,15 @@ Multiple "def" keywords, one which would mean side-effecting function
270
278
271
279
**Josh** points out that current developers would need to change their habits but motivation lies in introducing new developers to Scala and having this consistency to help them stay, given that as it is now it takes longer to learn and making mistakes here is bad.
272
280
273
-
**Jorge**Intellij already warns developer whenever they use procedure syntax, and suggests them to rewrite it with an automatic rewrite. It’s true that not all Scala developers use IntelliJ, but a big part of do, and thanks to IntelliJ they are strictly discouraged to use procedure syntax.
281
+
**Jorge**IntelliJ already warns developer whenever they use procedure syntax, and suggests them to rewrite it with an automatic rewrite. It’s true that not all Scala developers use IntelliJ, but a big part of do, and thanks to IntelliJ they are strictly discouraged to use procedure syntax.
274
282
275
-
**Eugene**[YouTube time: 50’49’’](https://youtu.be/gnlL4PlstFY?t=3049) asks what is the migration strategy; is it possible to do a batch migration for the big code base or would it be necessary to go through your code in IntelliJ? More? https://youtu.be/gnlL4PlstFY?t=3049
283
+
**Eugene**[YouTube time: 50’49’’](https://youtu.be/gnlL4PlstFY?t=3049) asks what is the migration strategy; is it possible to do a batch migration for the big code base or would it be necessary to go through your code in IntelliJ?
276
284
277
-
**Seth** reminds the viewers/Committee that it was deprecated only in 2.13 OM4, which is probably why this proposal got so many responses.
285
+
**Seth** reminds the viewers/Committee that it was deprecated only in 2.13 OM4, which is probably why this proposal got so many responses.
278
286
279
287
**Conclusion** Before making a final decision, the proposal needs a better motivation 1. Why it is safer 2. Refactoring tools / parsing 3. IntelliJ tool explained?
[“Proposal to remove early initializers from the language”](https://contributors.scala-lang.org/t/proposal-to-remove-early-initializers-from-the-language/2144);
285
292
[“DelayedInit or OnCreate, any solution?”](https://contributors.scala-lang.org/t/delayedinit-or-oncreate-any-solution/1748)
[“DelayedInit or OnCreate, any solution?”](https://contributors.scala-lang.org/t/delayedinit-or-oncreate-any-solution/1748)[YouTube time: 59’35’’ - ’](https://youtu.be/gnlL4PlstFY?t=3575)
298
+
[“DelayedInit or OnCreate, any solution?”](https://contributors.scala-lang.org/t/delayedinit-or-oncreate-any-solution/1748)[YouTube time: 59’35’’ - end ’](https://youtu.be/gnlL4PlstFY?t=3575)
292
299
293
300
**Conclusion** to sleep on it, 14 days left on the Contributors thread…
0 commit comments