About that Kotlin notion

[EAGrahamJr]

A project goal, as stated in the description, is to utilize functional aspects as a design pattern. Kotlin is pretty much there and actually adds very little overhead in terms of library requirements (most of it is to set up the Kotlin compiler, which is not used in applications or libraries).

Other things to consider (the things I really like):

• null-safety
• "pure" functional programming (no classes or objects required)
• dead-simple singleton pattern without monkey business
• Class and language extensions (like operator overloading) for more expressive code
• quasi-multiple inheritance (it is but it isn't - actually delegation)
• Java interop

Most of my kobots repo is a bit of a mess, but the "utilities" sub-project is where I'm trying to get serious and has the latest "dev" code (adhoc is where I "live test" and boy do I really like that GRPC provider!!!!!).

I would be interesting to see what a whole-hog conversion would look like (Intellij's IDEA will do it for you), but I don't know if that would actually be useful or not. Possibly starting a separate sub-project¹ where new stuff (and slowly migrated items) could live with the Kotlin compiler. That would prevent wholesale destruction "downstream issues" for users of the libraries.

¹ I won't get into the Maven vs Gradle stuff. 😈

[mattjlewis]

I've attempted to do the Advent of Code challenges as a way to improve my development abilities and stay up to date with modern implementation approaches. As part of this I have attempted to embrace functional programming (and latest Java 21 features) as much as possible and must admit to really liking it.

Areas where I know diozero needs to improve includes:

1. Internal use of streams and APIs that expose streams (events?)
2. Use of Optional to avoid null object checks
3. Extract more interfaces / functional interfaces, in particular those relating to events
4. Other general tidy ups, e.g. adopting common IoT terminology, in particular clear demarcation between sensors, actuators, controllers and environment.
5. Consider a (separate?) package for useful algorithms, e.g. A*, Dijkstra, Monte Carlo, ... I can possibly take some of from my Advent of Code solutions.

I've always thought that I should tackle some Advent of Code stuff in Kotlin as well as building more Kotlin based diozero apps so that I can see further areas for improvement.

Always open for suggestions and feedback.

[EAGrahamJr]

One of my embrasures of Kotlin really is a lot of the functional aspect -- and it's quite amusing to see Java attempting to embrace (sometimes awkwardly?) a lot of what Kotlin has been doing for a while. But, nevertheless,...

1. Streams do not necessarily equate to "events": streams are simply a way of manipulating data. If, on the other hand, you're referring to flows, yes, that's definitely a ripe area for consideration (Pub/Sub). The caveat is you can get too "clever" and go overboard (did this myself with an "event bus" thing).

2. Yes. null sux

3. See DigitalInputDevice that doesn't check if a listener is already associated to a pin in the setInputListener() #1 - define "events". To be honest, I'm actually more inclined to ensure that critical resources are thread-safe and let the user shoot themselves in the foot manage any threading, simply because every situation is going to be different and trying to anticipate any particular user's case would be close to impossible.

4. Concur. I would possibly recommend trying to align with the Matter initiative, if you want to actually go more towards full on IoT.

5. I don't see the advantages of any of those algorithms, especially for a library intended to interface to hardware. In fact, the animation package makes my head hurt 😀 .

More thoughts later...

[EAGrahamJr]

I just got the 1.4.1 updates and I'm a little confused about a couple of things with the OLED devices (one of which I will likely be adjusting):

1. Why is there a "TextAlign" enum? The displays all take a BufferedImage and I would strongly suggest staying away from anything that really has to deal with the Graphics2D image handling (like text) - my opinion is that futzing with scaling and rotating is opening a can of worms that you may not want.
2. DisplayType.BINARY? I think you mean MONOCHROME... 😀 (I'll update that when I submit my re-done SH1106 device.)