There are three kinds of actuaries: those who can count, and those who can't.
Piet Souris wrote:hi Stanley,
it is the expresson 'c -> s.getCount() += 1' that is invalid. In fact, it boils down to: s.getCount() = s.getCount() + 1, which is invalid.
If you add the method
and make the Consumer:
then all is well.
There are three kinds of actuaries: those who can count, and those who can't.
There are three kinds of actuaries: those who can count, and those who can't.
Junilu Lacar wrote:Additionally, your usage of the Function and Consumer interfaces are smelly. I can't quite put my finger on it but it just seems like there's way too much unnecessary intimacy between the StateCount class and the lambdas. The lambdas having a reference to StateCount does not look right to me. And Consumer seems like the opposite of what you should use. That is, it seems to me a
ProducerSupplier is more appropriate for what you want to do. I'll try to come up with an example to show something I think is more sensible.
Junilu Lacar wrote:between the StateCount class and the lambdas
Piet Souris wrote:hi Stanley,
as said: it is not a question of whether a Function works and a Consumer doesn't, but the question what is a legal Function and what is a legal Consumer.
I must say: your code, although nothing wrong with it, is not very transparant. To make the error a little easier to spot, let's make a separate Function and a separate Consumer. If you get an error in one of these, then you know that the problem is not in the 's.changeState(2)' part of the code,
So here goes:
So, when we apply this function to some StateCount c, then the return value is c.count + 1.
On its own, c.count + 1 means nothing, you get a compiler error here, stating that this value should be assigned to a variable. Now have a look at the method 'stateChanged':
You invoke it with:
So, in effect, what you do is saying:
and as you can see, this is perfectly legal code.
Now for the Consumer part. Again, let's check if the Consumer as you defined it is correct:
As you will notice, this gives a compiler error, stating that an int (the result of the right part) cannot be converted to void, as a Consumer must be.
So, let's try a variant:
Now we return nothing, but as before, we get the error that the right hand part is not a statement and should be assigned to a variable.
Well, let's do that, but the way I do it makes it necessary to make the variable 'count' available to other classes as well: make it a public variable (that is bad practice, never do that in your code, but it is just for demonstrations sake)
And that is perfectly legal as well.
So, with the Function sToi and Consumer consumer defined (and legal), we can invoke them, either as you invoke them,but also as follows:
As said, having the separate sToi and consumer makes it just a tad easier to see what is going on.
Looking back, I must admit that this is actually not an easy subject at all! It is a subject that takes a lot of practising, and a lot of trying until you get it right! But the reward of putting all that effort is there: it is big fun working with all of these Consumers, Functions, Predicates and similar. Of course, if you have additional questions, just come up with them.
There are three kinds of actuaries: those who can count, and those who can't.
OP wrote:...trying out different ways to fail
OP wrote:why do you say "between the StateCount class and the lambdas"
Java API Documentation for Consumer wrote:Unlike most other functional interfaces, Consumer is expected to operate via side-effects.
Junilu Lacar wrote:Additionally, your usage of the Function and Consumer interfaces are smelly. (...)
There are three kinds of actuaries: those who can count, and those who can't.
There are three kinds of actuaries: those who can count, and those who can't.