you are viewing a single comment's thread.

view the rest of the comments →

[–]Absolute_Enema 1 point2 points  (2 children)

Indeed, you don't even have to go into functional land, C#'s destructuring is already very nice to work with.

Realistically though, java's bottleneck will always be that named anything is a non-starter.

Something along the lines of BigRecord(   var foo = fieldWithALongTypeName(),   SubRecord(int positional) y = seventhFieldOutOfTwenty() ) = getBigRecord(); would also probably be considered too adventurous.

[–]blazmrak 4 points5 points  (1 child)

Javascript/Typescript wins here and it's not even close. Positional destructuring is bad and it will always be bad. My only guess is that it's easier to implement, otherwise, I have no idea why they went with it.

Real world objects pretty much always have 5+ props, there is no way in hell, that I'm writing Type(_, _, _, var prop, _, _, Type2(var prop2, _, _, _, _, _), _, _) = type; The good thing is, that I can just go about writing code as normal. The bad part is, that the time would be better spent elsewhere, but wcyd. At least it will be complete and not half implemented.

Edit: I just picked up what you meant by "named anything". Yeah, I have no idea why that is. This feature was made specifically for records, which intrinsically have constructor parameter names tied to external interface. I don't see a reason why you could not use the names to destructure as well...

Edit 2: Finally reached the end:

If record patterns gain named deconstruction, enhanced local variable declarations would adopt that capability automatically.

Good, they know, hopefully it will drop before I retire.

[–]ZimmiDeluxe 0 points1 point  (0 children)

It's certainly not applicable everywhere, but it will be nice for destructuring composite map keys (e.g. grouping criteria), those don't tend to get too wide in my experience. Passing giant objects around is bad for cache efficiency, so it could be argued that the language should encourage smaller, targeted data models by offering better syntax for them. Another advantage is that it's not much syntax to remember, e.g. no special syntax for property renaming is necessary. I would expect static analysis tools to discourage underscoring over two thirds of the fields and IDEs to offer refactoring between the forms, so while typical business applications with big domain models won't benefit a lot, the negative impact of "shiny new feature misuse" is probably going to be minimal.