# What is Vassal and its core function? **URL:** \ **Category:** General Discussion\ **Created:** [June 14, 2022, 2:50pm UTC](https://forum.vassalengine.org/t/what-is-vassal-and-its-core-function/74815 "2022-06-14T14:50:58Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![uckelman](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/uckelman/32/10020_2.png) [@uckelman](https://forum.vassalengine.org/u/uckelman)\ **Post date:** [June 14, 2022, 9:45pm UTC](https://forum.vassalengine.org/t/what-is-vassal-and-its-core-function/74815/2 "2022-06-14T21:45:37Z")
You won’t find anybody advocating for the way things are now. It’s an odd, idiosyncratic contraption. I reluctantly concluded that all of this needed to be junked a decade ago. Here’s what I wrote on the topic in 2020: > [@Vassal 4 vs Java](https://forum.vassalengine.org/t/vassal-4-vs-java/11394/12): > > You can’t refactor reliably without tests. I started writing tests for Vassal more than a decade ago and made little headway. Almost nothing was in a testable state already, so would have required refactoring prior to having any tests, putting us at risk of breaking things without knowing it. In many cases, I couldn’t establish conclusively how things were supposed to behave, so couldn’t write tests even when things were testable. Finally, the way that custom module code was allowed access to the library code made nearly everything a public API, so it’s extraordinarily hard to refactor anything in a way that doesn’t break modules. All of this applies to fixing bugs as well. You saw exactly what I’m talking about here play out with the grid numbering problem. More, from 2020: > [@Vassal 4 vs Java](https://forum.vassalengine.org/t/vassal-4-vs-java/11394/3): > > From my point of view, the purpose of much of the work since last fall has been to get V3 into a state where it doesn’t require much maintenance, in order to give me time to work on V4 while people use V3. We’ve mostly arrived there now, though when I wrote this I was expecting 3.5 to be the destination instead of 3.6. Responding specifically to your request for a spreadsheet component in V3: - I don’t know of any Swing-based spreadsheet components. Building the GUI for one from scratch starting from a JTable would be a huge job. - You’d need an expression evaluator, and the most obvious candidate for that is Beanshell. Writing an expression evaluator from scratch is likewise a huge job. - You’d need a way to refer to properties, and that couldn’t differ much from the way they are referred to now. What you’re asking for would be a major time commitment, and developer time is a finite and precious resource. I try to spend my own development time on things which will push back the day when we can no longer keep V3 working or bring forward the day that V4 will be usable. Adding a spreadsheet feature to V3 won’t do either of those things. I won’t work on it. Maybe you can convince someone else to try; I’d argue that’s throwing good time after bad. If you want C-style arithmetical expressions and natural syntax for direct property access, that can be had essentially for free with JavaScript as the scripting language, which is where we’re headed with V4. That, and a human-readable file format, is what will cut through the mess you’ve described. --- _[View the full topic](https://forum.vassalengine.org/t/what-is-vassal-and-its-core-function/74815)._