Each of these projects has a vendor folder from which you can find more inspiration.
Some of the experience of doing all this is captured in https://status-im.github.io/nim-style-guide/.
https://github.com/elcritch/figuro seems to be worth studying as it uses OOP for when it's the best paradigm, UIs.
It uses idiomatic Nim as far as I've looked at it. But whether to use OOP or not should depend on your problem domain, Java's mistake is that it claims it's good for every domain. I beg to differ and think it's only good at some domains and most domains are better served by imperative modular code that was popular before OOP became dominant.
The idea of not hiding data feels unsafe.
You don’t need OOP for that. Nim’s module system makes bindings private by default unless you explicitly export them.
I also use Java mostly, old and ugly, but pays well.
Try avoid OOP unless you really need it. It's rarely needed. The Java Design Patterns are rarely applicable to functional programming.
P.S.
... Java's mistake is that it claims it's good for every domain ...
I think it doesn't matter anymore, because in next 2-3 years all traditional programming langs be it Java or any other will be obsolete. Yet, Java has very strong advantages, it got most important points right:
What's important is to not fail. As for project cost and time x2-4 more is ok. As for servers - nobody cares at all, if it's 1 server or x10 or x30, those are pennies.
I'd highly recommend reading Pixie as it's just a beautiful library and core to Figuro.
Figuro does use object inheritance quite a bit as @araq points out. However Figuro doesn't use Nim's methods and instead uses ref objects + inheritance along with slot and signals from QT. Signals and slots are more akin to Smalltalk style objects and message passing which many believe to be superior for GUIs. That's a whole other sub-topic though. Though checkout my sigils library if you want enlightenment. ;)
Most modern languages do separate out object inheritance and the implementation of methods, preferring composition over methods.
The idea of not hiding data feels unsafe.
That's stockholm syndrome. ;) Nim private fields do allow hiding data. That said, having transparent data structures is generally better IMHO. I rarely ever saw useful cases for Java OO style data hiding with getters and setters and such outside of dealing with the complexity due to Java-style OO.
For the few cases where POJO style getters and setters are useful, Nim has a syntax for providing setters (aka properties). Properties have been adopted in Python and Obj-C (Swift?) as well.
I'd also say much of Joe Armstrong's critique of OO applies for Nim despite it not being a functional language: https://www.cs.otago.ac.nz/staffpriv/ok/Joe-Hates-OO.htm
However researching Nim and OOP suggests they don't play well together.
It's less that they don't play well together, but more that Nim's approach doesn't require it as much and so has less support for things like interfaces. In some ways it's similar to the differences between C++ OO programming and the STL template first approach that evolved later. If you're not familiar with it there's undoubtedly some good Youtube videos that'd be worth a watch.
Concepts in Nim (and C++) roughly fill a similar role that interfaces provide in other modern languages. They have some rough edges in Nim, but are useable.
So I'm wondering what is the paradigm shift I need to make with making objects available to the methods/functions that interact with them (for example).
I'd recommend as a beginner feeling free to just use ref object until you get more familiar with value vs ref types. Longer term learning to work well with "value types" is key to good performance in Nim and reducing side effects, controlling mutability, etc.
Generally avoid methods unless you really need to have different behaviors without knowing the specific types you're working with. With a bit of generics or concepts you can avoid methods most times. That said I recently used methods in Figuro for some internal windowing stuff because it was easier than generics.
Lastly Nim's UFCS let's you write code as if it's using methods, but without the hassle of writing methods. It's quite nice.
I'll agree on OOP. I can't find it useful in webdev, because webdev fundamentally is about giving commands that change data and query data, an OOP metaphor just always gets in the way there from what I could tell using Spring.
Imo for GUI it's declarative programming that works best as a paradigm (where nim's metaprogramming can work well to provide a declarative language). For backend it's imperative and I don't really have much more expertise in other areas.
stockholm syndrome
😂 the java hostage crisis
Signals and slots
Can you say in a nutshell why this is better than having a list of procedures that get called when the user takes a certain action on a widget?
The standard library. The github repos of @treeform, @guzba, @johnnovak.
But, there is a lot to list, is there a specific field you want to use Nim for? Looking at the code similar to what you've done may make the dive easier.
Can you say in a nutshell why this is better than having a list of procedures that get called when the user takes a certain action on a widget?
I couldn’t find a good summary article, but here’s a short list:
Signals & slots are a generalized observer pattern. They’re connected based on names rather than a list of callbacks. Just having a list of callbacks is harder to inspect, to provide idempotent connections, or disconnects. There’s more boilerplate doing callbacks on each widget.
For my work at least, this is a major advantage of the signal/slot pattern