appearandly theres are checking-in hooks, if there are check-out hooks then we can implent this and client with check-out hooks can use w/e they want in there only formatting world. Lets call it format-round tripping, if that makes it clearer. And since we work at the same level of abstraction the con's of the other/normal 'round tripping' are absent.

although it is useless in the light of the above, I'd like to know that my preference goes to sticking the { at the end. And no I don't do it to save lines, I do it because it's easier to reconise indents and use indents to reconise structure, then it is to actually read anything. And it's inconsistend or do you also write

appearandly theres are checking-in hooks, if there are check-out hooks then we can implent this and client with check-out hooks can use w/e they want in there only formatting world. Lets call it format-round tripping, if that makes it clearer. And since we work at the same level of abstraction the con's of the other/normal 'round tripping' are absent.

Just as cylab already mentioned, checkin hooks will cause a lot of diffs, as well as check-out-hooks will.

although it is useless in the light of the above, I'd like to know that my preference goes to sticking the { at the end. And no I don't do it to save lines, I do it because it's easier to reconise indents and use indents to reconise structure, then it is to actually read anything. And it's inconsistend or do you also write

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

for{

}

if{

}

static{

}

syncronised(mutex){

}

Of course I do. And all the others prefering next-line-braces will also do. What did you think?

Just as cylab already mentioned, checkin hooks will cause a lot of diffs, as well as check-out-hooks will.

check out hook will eliminate diffs.formatting1 -> conversion on check in --> formatting2[server]since everything thats checked in at the server is in formatting2 it will not cause diff's on the serverformatting2[server] --> conversion on check out --> formatting1since everything thats checked out at the client is in formatting1 it will not cause diff's on the client

perhaps a more programmer like abstract example will work.say at the server I'm using 10 digit system.Theres a 4 on the server.The client attemps to check the 4 outthe check-out hook is run and the 4 is converted into a 2 digit system resulting into 100The client then checks in the 100the check-in hook is run converting it to a 44 is compaired to the excisting 4 causing no diff (4 eq 4) <-> trueif the client checks it out again it converts it back to 2 digit system resulting into 100again it's the same as the excisting is 100 and the server returns 100.

some clairifications: the check-out hook is not at the server but at the client.code formatting conversion doesn't require knowlage on the excisting code formatting. (as opposed to the example where 100 could be interpered as a 100 (10system) as well as 4(2digit) as long as the code is syntaxly correct there are no problems but since there are undoubtly also check-in hooks that could check the syntax it shouldn't cause problems.

It's not like they come to the 'Xith board', they just click 'show unread posts', so you'll probablynever see them again around here, some may not even have noticed they are posting on a Xith board.

Finally, would you really want to have all those visitors, on your Xith board that do not chat about Xithbut something that is a matter of taste? Nobody will change their taste because of this whole thread.

My final words here... or I'd be joining this time-wasting effort

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

Finally, would you really want to have all those visitors, on your Xith board that do not chat about Xithbut something that is a matter of taste? Nobody will change their taste because of this whole thread.

Yeah but maybe you missed the thing about server-side hook-in testing, and automatic reformatting.. which is pretty interesting anyway...

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org