Yes, but the "final" is a special modifier - translated to wicket one
would expect a method "addUnique(...)" and not the strict add we
currently have - now we have a strict "add(..)" and a nonstrict
"addOrReplace(..)"
Best,
Korbinian
Am 18.11.10 14:49, schrieb Martijn Dashorst:
Well, the compiler will give you an error when you do:
final String foo = "Foo";
foo = "Bar";
The difference is in naming: add() currently does exactly what it
says. addOrReplace does also exactly what it says. Having clear
meaningful names is a good thing to have.
Deprecating add in favor of addOrReplace() would have a different
effect: more verbose (but meaningful) code...
Martijn
On Thu, Nov 18, 2010 at 2:40 PM, Korbinian Bachl - privat
<korbinian.ba...@whiskyworld.de> wrote:
Hi,
I don't use jRebel but the differentiation of the add and addOrReplace
method is something that I still don't understand what it's good for.
Actually if you do in java:
String foo;
foo = new String("world");
no one ever would think about throwing an error because one does
foo = new String("no World"); later on
This add(new Label("foo","message")); should behave IMHO the same as
overwriting objects (and here we just put a new object to the add method) is
just natural in java as everyone of us does it every day.
IMHO: make addOrReplace deprecated in next 1.4 release and give add the same
behaviour as current addOrReplace; in 1.5 addOrReplace can be stripped
completely;
my 2 cents - now flame on me :)
Am 18.11.10 14:25, schrieb Martijn Dashorst:
Relaxing the add() method has been proposed before (by Eelco). It is
not something new, and if it helps people using jrebel to improve
their productivity, that would be a great side effect.
The workaround is indeed to go back to a different page and do the
appropriate clicks again.
Martijn
