HI
I think your change is a good idea, but I don't really like using null
as an indicator of something special.
It sounds like an invitation to make mistakes about when the parameter
is or is not useful.
Why don't we just make this a special case and drop the previous
parameters?
I can't see
When selection changes directly, we simply pass the old selection state to the
listener, since there is basically no overhead in doing so. When it changes
indirectly, we'd have to manually create the previous selection, which is an
unnecessary performance hit.
On Jun 24, 2010, at 10:12 PM,
Martini [mailto:sandro.mart...@gmail.com]
Sent: Thursday, June 24, 2010 5:53 PM
To: dev@pivot.apache.org
Subject: Re: [RFC] Selection change events
Hi Greg,
for me the change is right, and maybe with this application selection
listeners could see what to do (and when it's the case ignoring
Hi Noel,
I did think about removing that argument, but there are a few reasons why I
didn't think it was the right approach:
1) All of our other property change events carry a previous value, so this
would create an inconsistency.
2) I think there are potentially valid use cases for it. Let's
Hi
OK, I see your case.
I'm just concerned about the sometimes previousSelected is available,
sometimes it's not situation.
Perhaps we should rather just take the complexity knock and always work out the
previous selection - what was the
problem here again?
-- Noel
Greg Brown wrote:
Hi
It would be a needless performance hit. Every time you add or remove an item
from the model, we'd need to create a copy of the entire selection state just
to include it in the event. Since, as you pointed out, the common case is
probably to ignore the previous selection argument, this would be
, 2010 9:30 AM
To: dev@pivot.apache.org
Subject: Re: [RFC] Selection change events
It would be a needless performance hit. Every time you add or remove an item
from the model, we'd need to create a copy of the entire selection state
just to include it in the event. Since, as you pointed out
The performance impact should be negligible.
On Jun 24, 2010, at 5:52 PM, Sandro Martini wrote:
Hi Greg,
for me the change is right, and maybe with this application selection
listeners could see what to do (and when it's the case ignoring the
indirect change event, like today) ... and on all
The performance impact should be negligible.
I was sure of it :-) ...
Message-
From: Sandro Martini [mailto:sandro.mart...@gmail.com]
Sent: Thursday, June 24, 2010 5:53 PM
To: dev@pivot.apache.org
Subject: Re: [RFC] Selection change events
Hi Greg,
for me the change is right, and maybe with this application selection
listeners could see what to do (and when it's
10 matches
Mail list logo
