i'm a reseller and i haven't heard of any problems with the core stuff (UML, SysML). I run it on Windows 10 and Linux with Wine

It's not a problem with the product, its a problem with the people not wanting to learn

@permalmberg that's what i mean by uml in general. that has taken a beating in recent years with supposed agile process which often is taken to mean cutting corners

ah. true that.

Its another thing I'm fighting. Agile != cut corners.

yeah. i have been in a lot of places where agile is waterfall, but you stand up during the meeting

Just because you open to change doesn't mean you don't things properly

Haha yeah

So that's what it's like stepping away from this channel for 20 minutes and trying to catch up with the backlog 😆

This is the place where it happens 🙂

@permalmberg I use EA for all of my consulting engagements, but not as an official part of the engagement although I deliver the documents. As I analyze legacy code, I just start chucking things into a UML model. After a while that model starts to become pretty useful.

Yeah, I second that, @carlw

Its worth lots and lots.

i might put it down while i code, but when i come back to it a few weeks later, it's easy to pick up from where i left off this is in comparison to a drawing tool or notes

I try to keep my docs updated as I code...makes it easy to see when you start making trouble for yourself 😛

@Ruckus Did you see http://stackoverflow.com/questions/42097798/in-tornadofx-how-can-i-bind-bigdecimal-properites-to-another-bigdecimal-propert ? I suspect he's really wondering why he gets

ObjectBinding<BigDecimal?>

instead of

ObjectBinding<BigDecimal>

. Do you know why we made the return type nullable here?

@Ruckus I think I figured it out. If the value we're passed from the observable is null, we must/can return null as well.

Exactly. Sadly, we can't define methods in Kotlin that work with system types (

T!

), so we have to force one way or the other, and this seemed like the safest bet.

I was about to answer him this:

All the

xBinding

functions returns bindings, not properties. If you think about it, how would a calculated property behave if it was writable? Should it write back into the underlying properties perhaps? TornadoFX actually supports these kinds of proxy properties as well, but I suspect that's not what you're after. Are you wondering why you get

ObjectBinding<BigDecimal?>

instead of

ObjectBinding<BigDecimal>

? The reason is that the underlying property might be null, and if so we might want to return null from the calculated binding as well. This normally doesn't create an issue, the property is still observable and would carry the correct calculated

BigDecimal

value.

Would that be correct?

@edvin What do you think about encouraging Double? You'd be able to bind with the add() and substract() and other math expressions. Not sure of his precision requirements...

@edvin I use the comparisons too

@carlw I think he's aware of the double bindings already, so I guess he needs BigDecimal. Double is not good for money for example.

@edvin That sounds like it sums it up pretty well.

@edvin ok...you miss out on things like interest.isGreaterThan(0) , etc

@edvin Also, we're in the presentation so there may be some opportunity lower-down (say a model) to introduce the true number representation

@carlw Without knowing his use case, it's hard to know if Doubles would even work, let alone be acceptable. But it wouldn't be too hard for him (or anyone) to define

fun ObservableVaule<BigDecimal?>.isGreaterThan(...): ObjectBinding<BigDecimal?>

(and other such functions)

@Ruckus Right. if you need a BigDecimal, there's no way to add back the precision. I was thinking though if there was a way to reframe his problem with standard JavaFX / TornadoFX like keep the BigDecimal in the model but show and bind to a Double

Ah, I see