<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Ron Pressler" <ron.pressler@oracle.com><br><b>To: </b>"Remi Forax" <forax@univ-mlv.fr><br><b>Cc: </b>"Dan Heidinga" <heidinga@redhat.com>, "Brian Goetz" <brian.goetz@oracle.com>, "amber-spec-experts" <amber-spec-experts@openjdk.org><br><b>Sent: </b>Monday, February 20, 2023 10:47:57 AM<br><b>Subject: </b>Re: Implicit Record Was: JEP draft: Implicit Classes and Enhanced Main Methods (Preview)<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">
<div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
I was trying to understand how you tie shared variables to encapsulation and what you meant by something that students later need to unlearn, and I think I understand now. You’re okay with shared mutable state as long as it’s clear that it’s not shared with
the whole world but only with some explicit unit, and since an implicit class appears to be the whole world, then its fields seem to be globally shared, and that’s what you want to avoid your students learning. Is that correct?
</div></div></blockquote><div><br></div><div>yes. But it's one of the arguments.</div><div><br data-mce-bogus="1"></div><div>The real problem is dangling fields. Conceptually fields are far more "attached" to a class than methods (at least until you explain classes) but syntactically with an implicit class, you do not see that. Allowing dangling fields force the teacher to explain what an implicit class is which defeat the teaching purpose of it.</div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class="">
</div>
<div class="">Now, we’re not in the business of telling teachers how to teach, and I assume different teachers teach in different ways. Implicit classes are not exclusively a teaching construct, but a natural Java construct — a natural extension of implicit
modules and packages. </div></div></div></blockquote><div><br></div><div>Agree, but there are some fundamentals, introducing fields without the notion of class is hard to envision.<br></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Expert programmers may also appreciate implicit classes just as they appreciate JShell and launching source-code programs, both of which are also explicitly motivated, at least in part, by education (see JEPs 222 and 330).</div></div></div></blockquote><div><br></div><div>yes,<br data-mce-bogus="1"></div><div>Here we are discussing about ergonomics, i.e. is the "natural" extension is implicit class or implicit record ?<br></div><div>With JEP 330, it's fear easier to create one file scripts written in Java instead of Python mostly because Python on Windows does not work as well as Python on Linux. I've seen several of those scripts on github, and there are not all using "class" as the top-level containers, some are using "interface", i've not seen a lot of scripts using records but record is a more novel construct. Implicit class is not necessary the right default. </div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div class=""><br class="">
</div>
<div class="">That natural Java construct *allows* teachers to teach in the order and style they choose without *forcing* classes on them. Some teachers may teach just basic control flow and (local) variables, perhaps records, and treat List, Map, and Set as
built-in constructs without teaching any OOP in the first course and without teaching students how they can implement their own Lists etc. Some may choose to show shared variables (even if only to demonstrate their danger) while some may choose not to, although
I assume everyone will teach constants. If you want to teach mutable fields only after introducing classes, that’s great and you can certainly do that (perhaps while enjoying the enhanced main and postponing static). But I don’t think the language should enforce
a particular teaching style, where shared mutable state *must* be taught only in the context of classes. Even if you believe that doing otherwise is bad pedagogy, there is nothing that fundamentally ties shared variables to the ability to create class instances. </div></div></div></blockquote><div><br></div><div>Agree, i'm not suggesting that there is a right way to teach, i'm too old for that :)<br></div><div>Before implicit class, introducing field declarations without classes is not something that was possible, so dangling fields is a new feature. As a teacher, the main reason to not allow dangling fields is that it creates confusion between local variables and fields which is a real issue students wrestle with.</div><div><br data-mce-bogus="1"></div><div>Also, as a side remark, implicit class/record also creates new challenges from the teaching perspective, by example, you have to postpone explaining static quite a bit otherwise if you explain that main() can be a static method too soon, students will call you because this kind of code does not work<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div> <div> static void main() {</div><div> var color = new Color("blue"); // oops</div><div> }</div></div><div><br data-mce-bogus="1"></div><div> class Color(String name) {<br data-mce-bogus="1"></div><div> ...<br data-mce-bogus="1"></div><div> }</div><div> <br></div><div><br data-mce-bogus="1"></div><div>My point is that while i agree that having an implicit container is a good idea, it does not make necessarily teaching easier, because an implicit container is a new feature that may interact badly with the rest of the features you want to teach.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div class=""><br class="">
</div>
<div class="">It’s true that we don’t want to cause harm by letting beginners learn something that needs to later be unlearned, but that’s not the case even for those who do learn about mutable fields. If students begin with implicit classes and seem to think
that fields (if taught them) — or methods for that matter — are shared with the whole world, they invariably later learn that their “whole world” is actually a unit and that big programs are made by composing such units. They inevitably learn that because
Java offers no other way. They *can’t* create a global variable, nor a global method, because Java simply doesn’t have those. Even if Java were to someday acquire package-level fields and methods (or even, hypothetically, module-level methods and fields),
it still wouldn’t have a global namespace (not even for classes!). Learning that basic fact doesn’t require any unlearning, just contextualising.</div></div></div></blockquote><div><br></div><div>Everything is encapsulated in Java, but dangling fields syntactically does not show that, that the issue. <br></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div class=""><br class="">
</div>
<div class="">So we're giving teachers more freedom than ever before to teach Java in the manner each of them chooses, and I don’t think we’re inflicting any harm in the process. I think that restricting the abilities of implicit classes further forces a particular
teaching style — though some may consider it the only correct style — and would also be a less natural Java construct and a less enjoyable one for experienced programmers.</div></div></div></blockquote><div><br></div><div>The point is to teach Java, not to have to teach yet another new feature. Offering new freedom also implies introducing new complexity.</div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div class=""><br class="">
</div>
<div class="">— Ron</div></div></div></blockquote><div><br></div><div>Rémi<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class="">
<div><br class="">
<blockquote class="">
<div class="">On 18 Feb 2023, at 07:11, <a href="mailto:forax@univ-mlv.fr" class="" target="_blank">
forax@univ-mlv.fr</a> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">
<div style="font-family: arial, helvetica, sans-serif; font-size: 12pt;" class="">
<div class=""><br class="">
</div>
<div class="">
<div class="">yes.</div>
<div class="">from my experience, the time to introduce the notion of class is when you start to have shared mutable state. What i do not like with the implicit class proposal is the fact that you can have fields without defining the class around.<br class="">
</div>
<div class="">But i think there is a solution.<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">What about the feature being renamed to "implicit record" instead of "implicit class" ? We have no discuss why the container of an implicit "class" has to be a class instead of an annotation, an interface, an enum or a record.<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">Having the container to be an annotation is useless given that an annotation can not have a main.<br class="">
</div>
<div class="">If the container is an interface, methods are abstract by default which is not what we want.<br class="">
</div>
<div class="">If the container is an enum, then we are closer to the idea of Ron that it is a singleton, especially if the container defined one implicit enum member like "SINGLETON" . An enum can not be inherited and the default constructor is private which
is are nice properties.<br class="">
</div>
<div class="">if the container is a record with no component, it can not be inherited, the constructor is package visible and more importantly to me, a user can not defined instance fields ...<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">I prefer implicit record to implicit class because with a record as container you can not introduce a shared mutable state by error, you have at least to write static in front of the field.<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">I dread about students being able to write code like this<br class="">
</div>
<div class=""><br class="">
</div>
<div class=""> String name;<br class="">
</div>
<div class=""><br class="">
</div>
<div class=""> void setName(String name) { this.name = name; }</div>
<div class=""> void hello() { System.out.println(name); }<br class="">
</div>
<div class=""> void main() {<br class="">
</div>
<div class=""> setName("Bob");<br class="">
</div>
<div class=""> ...<br class="">
</div>
<div class=""> hello();<br class="">
</div>
<div class=""> }<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">i.e to be able to declare mutable shared state without a class around (@Ron without class encapsulation).</div>
<div class="">At least if the container is a record, "name" in the example above has to be static, from the student POV, an unusual variable.<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">An implicit record has also the advantage that you do not have to introduce the notion of class to explain the notion of implicit container, given that records are far simpler at the beginning than class, having the implicit container being a
record make sense because it's records all the way down.<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">What do you think about having the implicit container being a record instead of a class ?<br class="">
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div><br></blockquote></div></div></body></html>