Reporting a minor pain point I had when working with Sealed Types recently

Brian Goetz brian.goetz at oracle.com
Tue Nov 7 15:33:27 UTC 2023


Local sealed classes live on that list of features that are reasonable 
to do, but always seem to have less leverage than other features we 
could work on. We've gone through a few rounds of removing unnecessarily 
nesting restrictions (e.g., local records, allowing statics in inner 
classes), but there is always more to do.  Local sealed classes is one 
of these.  (Local methods is another.)

As you've observed, the workaround is obvious; move it to an outer level 
of nesting, or into a local class.

On 11/7/2023 10:10 AM, David Alayachew wrote:
> Hello Amber Dev Team,
>
> I have been making extremely frequent use of sealed types and records 
> to model Abstract Data Types, but the lack of local sealed types is 
> becoming more and more of an annoyance to me.
>
> Annoyance is the correct word -- the cost I pay is in wasting time 
> refactoring things. On rare occasions, I will refactor incorrectly and 
> have to spend about 15-30 minutes reteaching myself what each one 
> meant. This is certainly not an expensive cost. But this past week, I 
> hit this problem multiple times back to back, such that the sum total 
> was a few hours of refactoring across a full week of work. Because of 
> that, this email felt warranted.
>
> To very quickly explain my situation, I have a bunch of projects I'm 
> working on, each of which does a lot of work deserializing 
> semi-structured outside data. So, an ideal use case for ADT's. I keep 
> running into the same bar over and over again -- a project has many 
> different types of data it needs to deserialize (>20 different data 
> types), and several of those data types are quite similar to each 
> other, such that the names end up being similar. When I go to refactor 
> a class - either splitting it up or combining multiple classes into a 
> single one, I usually end up either mixing up sealed types (using the 
> incorrect one) or combining parent classes that both have private 
> sealed types with the same name.
>
> This week was notable because almost all of my projects that I am 
> working on ran into this same problem at around the same time.
>
> It's not a very big issue, but out of the 60+ hours I worked this 
> week, I'd say about 3-4 of those hours were spent debugging and 
> wasting time on fixing refactoring bugs. Admittedly, that's probably 
> the worst-case scenario one can get for this problem, which shows that 
> the scale of damage isn't very large. Also, I am pretty sure I know 
> the reasons why it hasn't been done yet, and I don't contest them. 
> However, I do want to share my experience in case that information 
> influences any decision-making on the matter.
>
> Thank you for your time!
> David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20231107/2100e03e/attachment.htm>


More information about the amber-dev mailing list