ImportExcel VS amber-docs

You might be able to use https://github.com/dfinke/ImportExcel to alter single cells in a csv file but I'm not 100% sure.

Maybe look at ImportExcel, it allows to put any list of objects right into Excel sheets, with insane customization capabilities.

Take a look on the PS ImportExcel Module. More info on the Dev's github site an dlot of examples.

There is a fantastic Module called Import-Excel you can download. It allows you to manipulate/export Excel files without needing to have Excel on the machine. I do not know if Import-Excel allows you to refresh data sources though.

Additionally, as /u/CarrotBusiness2380 already mentioned, Doug Finke has written the ImportExcel PowerShell Module, which utilizes the aforementioned SDK.

There are lot of sample on the Doug Finke GitHub site (the dev), and lot of site with articles about "how to use it". Take a look on this very useful module.

> "Sometimes the feedback involves making a minor tweak on every Worksheet."

Could be a good task for PowerShell and the ImportExcel module[1].

(PowerShell also being a .NET language and written in C#; it has convenient access to COM control of Excel if you can't import the spreadsheet and export an updated version; through $xl = New-Object -ComObject Excel.Application )

[1] https://github.com/dfinke/ImportExcel

https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...

This is the vague plan.

This kind of pattern matching is discussed in the design notes: https://github.com/openjdk/amber-docs/blob/master/site/design-notes/patterns/pattern-match-object-model.md

Or just stop trying to force immutability into something that is clearly mutable. You’re only causing unnecessary GC pressure by copying objects.

Never the less this eerily looks similar to Goetz proposal for reconstructors:

https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...

True, but that only pushes the question of value down the line.

I'm curious about lenses because Java did have a serious problem that required a solution: working with "simple" data correctly was difficult. The chosen solution was ADTs, so we did buy into that. But the approach being explored for transforming records (https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...) only works one level at a time rather than for an entire path. So I wonder how valuable it would be to have a solution for paths. If the answer is that it's mostly valuable for an approach we haven't bought into yet, then we might not need to consider it just yet.

Just a heads up, something like that spread operator is actually coming sooner or later to java: https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...

Pattern matching (for records) is already a preview feature.

Glad to see this is moving forward - I've been excited for this since first reading this writeup last year (I think.) I sincerely hope this also provides a nice platform for builders, though I'd prefer it if the syntax could be used to instantiate a new record rather than transform an existing one; it'd be neat to be able to do something like:

Java does not need and will not have first-class properties, at least not in any foreseeable future. However, better initialisation is a good requirement, but it can be solved with much better features than harmful properties, and work is being done on that.

The direction has been clearly explained all along.