<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body 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="">
On Jun 9, 2021, at 3:20 PM, Remi Forax <<a href="mailto:forax@univ-mlv.fr" class="">forax@univ-mlv.fr</a>> wrote:<br class="">
<div>
<blockquote type="cite" class=""><br class="Apple-interchange-newline">
<div class=""><span style="caret-color: rgb(0, 0, 0); font-family: Literata; font-size: 24px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">Sealed
hierarchies are restricted to a package in the unamed module in order to ease the migration when you add a module-info because a sealed hierarchy restricted to a package is obviously restricted to a module.</span><br style="caret-color: rgb(0, 0, 0); font-family: Literata; font-size: 24px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
</div>
</blockquote>
<div><br class="">
</div>
Adding module-info puts new restrictions</div>
<div>on the relations between packages. That’s</div>
<div>what modules are for. Subtraction of</div>
<div>privilege is a legitimate use of modules.</div>
<div><br class="">
</div>
<div>Adding new privileges is not a legitimate</div>
<div>use of modules, IMO. If moving to modules</div>
<div>is both additive and subtractive, you get</div>
<div>two incompatible access control regimes</div>
<div>(and even two languages), neither of which</div>
<div>is a subset of the other.</div>
<div><br class="">
<blockquote type="cite" class="">
<div class=""><span style="caret-color: rgb(0, 0, 0); font-family: Literata; font-size: 24px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">If
you relax that rule, you add another hindrance to the adoption of modules.</span><br style="caret-color: rgb(0, 0, 0); font-family: Literata; font-size: 24px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
</div>
</blockquote>
<div><br class="">
</div>
That’s backwards. The rule, in its current</div>
<div>form, is a an incentive to use modules</div>
<div>(to get more flexible behavior). But it’s</div>
<div>an unnatural incentive: It’s not what</div>
<div>language rules are good for.</div>
<div><br class="">
</div>
<div>The main “hindrance†to adding modules</div>
<div>is teasing apart cross-package accesses.</div>
<div>Having sealed classes be a Very Special</div>
<div>Case of cross-package accesses does not</div>
<div>help; it only makes the story murkier.</div>
<div><br class="">
</div>
<div>So, yes, removing the rule will remove</div>
<div>a twisted incentive to go to modules.</div>
<div>Is that “another hindrance†to modules?</div>
<div>Maybe, but it’s the right thing here.</div>
<div><br class="">
</div>
<div>— John</div>
</div>
</body>
</html>