<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>"Dan Heidinga" <heidinga@redhat.com><br><b>To: </b>"Ron Pressler" <ron.pressler@oracle.com><br><b>Cc: </b>"Remi Forax" <forax@univ-mlv.fr>, "amber-spec-experts" <amber-spec-experts@openjdk.org><br><b>Sent: </b>Friday, February 17, 2023 5:56:49 PM<br><b>Subject: </b>Re: [External] : Re: 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="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 17, 2023 at 11:05 AM Ron Pressler <<a href="mailto:ron.pressler@oracle.com" target="_blank">ron.pressler@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="overflow-wrap: break-word;">
I’d like to make another point about the general approach of this JEP.
<div><br>
</div>
<div>We try to avoid a beginners’ dialect, but a beginners’ *subset* is also not what we’re proposing. While the feature is primarily motivated by education, it is also a natural, perhaps even obvious, feature for Java that’s perfectly in tune with
the existing features of the language.</div>
<div><br>
</div>
<div>Classes, packages, and modules are all programming-in-the-large constructs, and every Java method resides in a class that resides in a package that resides in a module. Yet, when you don’t need encapsulation, an unnamed module is implicitly provided;
when you don’t need package namespacing, an unnamed package is implicitly provided. It makes sense to do the same for classes even to reduce the need for programming-in-the-large declarations in small programs. Of course, helping students is a bigger motivation
that makes significantly raises this feature’s priority.</div>
<div><br>
</div>
<div>The important question as is whether or not this feature fulfils the motivation of helping beginners (of course, it’s not the only feature we can or will do to that end). I think the answer is yes. So then the remaining question is, would subsetting
the language to forbid static members significantly help students? I’m not sure.</div></div></blockquote><br><div>Wouldn't forbidding static members impose a cliff on beginners? As they learn about static methods and fields and introduce the first static member to their implicit class, they'd be forced to grow a class structure around their program. Maybe that's a natural time to have to talk about defining a class? </div><br><div>I think there's a benefit in letting students (and advanced users) use as much of the language as possible in implicit classes. Don't force them to define the class until they do something that requires the class to have a proper name.</div><br><div>--Dan </div></div></div></blockquote><div><br></div><div>yes.</div><div>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 data-mce-bogus="1"></div><div>But i think there is a solution.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>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 data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Having the container to be an annotation is useless given that an annotation can not have a main.<br data-mce-bogus="1"></div><div>If the container is an interface, methods are abstract by default which is not what we want.<br data-mce-bogus="1"></div><div>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 data-mce-bogus="1"></div><div>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 data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>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 data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>I dread about students being able to write code like this<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div> String name;<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div> void setName(String name) { this.name = name; }</div><div> void hello() { System.out.println(name); }<br data-mce-bogus="1"></div><div> void main() {<br data-mce-bogus="1"></div><div> setName("Bob");<br data-mce-bogus="1"></div><div> ...<br data-mce-bogus="1"></div><div> hello();<br data-mce-bogus="1"></div><div> }<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>i.e to be able to declare mutable shared state without a class around (@Ron without class encapsulation).</div><div>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 data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>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 data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>What do you think about having the implicit container being a record instead of a class ?<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="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">
<div><br>
</div>
<div>— Ron</div></div></blockquote></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="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>
<div><br>
<blockquote>
<div>On 17 Feb 2023, at 10:11, Ron Pressler <<a href="mailto:ron.pressler@oracle.com" target="_blank">ron.pressler@oracle.com</a>> wrote:</div>
<br>
<div>
<div style="overflow-wrap: break-word;">
<br>
<div><br>
<blockquote>
<div>On 16 Feb 2023, at 21:41, <a href="mailto:forax@univ-mlv.fr" target="_blank">
forax@univ-mlv.fr</a> wrote:</div>
<br>
<div>
<div style="font-family:arial,helvetica,sans-serif;font-size:16px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
<br>
</div>
<div style="font-family:arial,helvetica,sans-serif;font-size:16px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
<div>I still think that fields should not be allowed inside an implicit class, because when you remove the class declaration a field and a local variable are too similar and because an implicit class has no user defined constructor.<br>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I think your general point has some merit — I’ll get to that later — but first let me address the concrete points you raise.</div>
<br>
<blockquote>
<div style="font-family:arial,helvetica,sans-serif;font-size:16px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
<div><br>
</div>
<div>Here is a series of examples showing how confusing it can be.<br>
</div>
<div><br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>How would any of those be made easier to understand by the presence of a class declaration when you don’t know what a class is?</div>
<div><br>
</div>
<div>By the way, we should certainly look into making some error messages — especially those encountered by beginners — easier to understand.</div>
<br>
<blockquote>
<div style="font-family:arial,helvetica,sans-serif;font-size:16px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
<div>Also conceptually, being able to define fields without constructors is problematic, because you are bypassing the the notion of encapsulation.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>
<div><br>
</div>
<div>Encapsulation from what? Encapsulation is a programming-in-the-large notion, but even at the technical level, an implicit class is well encapsulated by virtue of it being unnamed (and the default access remains package).</div>
</div>
<br>
<blockquote>
<div style="font-family:arial,helvetica,sans-serif;font-size:16px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
<div>Implicit class instance fields are more complex that usual class fields because of the lack of constructors.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
I’m not sure I understand the relationship you make to constructors (BTW, you can define initializers). </div>
<div><br>
</div>
<div>Python and JS, both also first language have a notion of shared variables that can be introduced before object fields. Clojure and ML, both functional languages, also have a similar notion of shared variables. Even Haskell has constants. Surely
you’d agree that at least final fields — constants — are necessary to do any kind of nice programming?</div>
<div><br>
<blockquote>
<div style="font-family:arial,helvetica,sans-serif;font-size:16px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
<div><br>
</div>
<div>Teaching using a simpler model is great but not if as a student you have to unlearn something previously introduced.</div>
</div>
</blockquote>
<br>
</div>
<div>I wholeheartedly agree, but what is the thing that needs to be unlearned?</div>
<div><br>
</div>
<div>But now back to where I think your general point has merit. I think final fields are a must, but one could certainly argue that non-final fields are not. You can certainly do a lot of programming without them. But I think that allowing final fields
and disallowing non-final fields *in Java* would be weird, because to designate something as final you need extra syntax, so we’d reject syntactically simpler, valid, code and accept more complex one. Moreover, there are things that are easier to do and tech
with mutable fields.</div>
<div><br>
</div>
<div>However, there’s the matter of static, which you used in your examples but didn’t explicitly discuss. Because a an implicit class is effectively a singleton (plus, the class cannot be referenced by other classes), there is no useful difference
between an instance field and a static field, so I think we should entertain the notion of disallowing static members — fields, methods, or even member classes (although things that are implicitly static, such as records would obviously be allowed).</div>
<div><br>
</div>
<div>One argument against that may be is that if an experienced Java programmer has an existing small program that they want to make prettier by turning into an implicit class — implicit classes are mainly motivated by learners, but they’re not *just*
for them — then the process would be made harder by disallowing static members.</div>
<div><br>
</div>
<div>In short, I think we must allow fields, but we can think about disallowing (explicitly) static members altogether.</div>
<div><br>
</div>
<div>— Ron</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote></div></div><br></blockquote></div></div></body></html>