Show more

A lot of work has been published surrounding formal satisfaction of boolean predicates since I received my degree. A lot of mathematical papers exist that probably make sense.

I've been looking for applicability in my own . Knowing that uses it means that some value can be derived from .

But to find it, it looks like a lot of reading.


While perusing the plugins that shipped with my package, I happened upon something called .

It is used by Eclipse to resolve its own source , and probably those of our projects as well.

At heart, this module can solve formal boolean expressions. For Eclipse, it looked to me like the PBS format would be an apt choice for those expressions.

I git trained in boolean logic.

and ? Not so much.

The problem with this is not, that there are no solutions to work around this limitation in the language. Solutions exist.

It's just that implementing those would require yet another load of copy-pasted, , which is exactly what I was aiming to avoid by using a base interface in the first place.

You're making it difficult to design clean architectures, Java.

Very difficult.

That required changing the declarations of the subclasses.

First: IMessage. Success!

Then IPair. No problems yet.

Then ILocateFiles. Uh-oh. Cracks are appearing. Alright: manageable.

Then NamePair. Kablammo! No more for me.

Thanks, language, that's exactly the level of architecture I always desired.


And as long as IEmptive is referred to as Consumer<? super IEmptive>, the world is fine, and is fine.

But that has a drawback: the auto-generated parameter value for the consumer is an IEmptive, rather than, say, a ReadFrom or a UserToken. That forces a type cast. This isn't necessary with Optional.ifPresent(Consumer).

So, can I get rid of that typecast?

The first thing I tried, of course, is to add a type parameter to the IEmptive interface declaration, much like Optional.

Why, you way ask? Because as it is in use as a base interface, my classes extend / implement it in various ways. Incompatible ways.

For instance:
IEmptive > IMessage > Message > XML.
IEmptive > IMessage > IName > Name.
IEmptive > IPair > ILocateFiles, IMessage > ReadFrom.
IEmptive > IPair, IName > Pair, Name > NamePair > UserToken.

So… ReadFrom is IEmptive, and so is UserToken. Both are IPair. And both hold IMessage values, though UserToken implements that as Name.

This got triggered a few days ago by me desiring to add consumer and function abilities to my base interface: doIfPresent(then, otherwise) and doIfEmpty(then), modelled after how 's own Optional class does ifPresent(Consumer).

But the Optional class is generified. And my base interface thus far hadn't been. And that makes a difference: the auto-injected argument to the Optional.ifPresent consumer is typed to whatever instantiated the Optional - 1/2

If they matched, my architecture wouldn't have needed multiple classes, now, would it? - 2/2

: Multiple inheritance in the language is problematic.

In my case, subclasses wind up with the same super interface via multiple inheritance paths. And as long as the super interface isn't generic, this gets resolved just fine.

As soon as we start generifying that super interface, Java will complain that the newly added varying type parameters don't match.

Well, no - 1/2

Ooh, a Samsung promo agent followed me. I wonder whether that is a spam account.

Lilo zu node-API: "Wann war das?"

node zu Datenbank: SELECT date FROM ...;

Datenbank zu node: 1740-01-01

node zu Lilo: "Biddesehr, 1739-12-31"

Lilo: "???"

Ich hätte da noch ein Forschungsthema zu vergeben: "Javascript Date() und seine Auswirkungen auf Datierungen in der Geschichtswissenschaft"

uk pol, brexit, venting, 320 words Show more

at least Pleroma is miles ahead in UX compared to Gab, jesus fucking christ what a piece of shit website honestly

The hidden costs of using Node Show more

Call me an old cynic: I just unsubscribed from Reddit's r/programming sub forum. It's filled with innane drizzle.

I'll focus on language and technology-specific forums, instead.

SDK 11.0.2 build 7 patches 5 critical security errors that "may be remotely exploitable without authentication, i.e., may be exploited over a network without requiring user credentials."

“We knew that something was amiss in the first couple days,” said Brad Lister. “We were driving into the forest and at the same time both Andres and I said: ‘Where are all the birds?’ There was nothing.”

Insect collapse: ‘We are destroying our life support systems’ | Environment | The Guardian

Show more

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!