On Wed, May 30, 2012 at 4:01 PM, Eduard Moraru
<enygma2002(a)gmail.com> wrote:
On Wed, May 30, 2012 at 4:16 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
On Wed, May 30, 2012 at 2:55 PM, Eduard Moraru
<enygma2002(a)gmail.com>
wrote:
> I mentioned Velocity because I saw a DiffScriptService component with
> @Named("diff") that has the same method signature as the Java API:
>
> public <E> DiffResult<E> diff(List<E> previous, List<E>
next,
> DiffConfiguration<E> configuration)
>
> See the discussion [1] on the pull request for more details on the
Velocity
> question.
>
> Back to my original question (same question as Thomas basically), that's
> exactly what I am trying to understand, Vincent... if the
> List<String/Character> is the optimal use case and not just String.
>
> Without a scenario in favour of List<E>, I would go for exposing a String
> based API (well, just an extra method in this case) as well.
You can imagine all sort of use cases with any value so I don't see
the point in arbitrary limiting the API to just Strings where the
logic is the same whatever the type.
Yes, I understand now how it works. If other are interested, please see my
new comment [1] on the pull request.
Short version: The API compares lists of objects by using Object#equals()
and does not go into the structure of the compared elements, just reports
differences of the list itself. You have to structure/break your input to
the level of granularity that you need for the diff to be relevant to your
use case.
If you really need a direct use
case for existing stuff then just think about producing a diff between
two static list properties values, it would be very bad to have to
create a String from it first especially since you could have \n in
one of the elements.
My main concern is to expose a clear API and no String it everything
but clear, it's simple yes but it's not the same things. When you
provide String you don't have no idea what you are diffing exactly
(could be characters, \n, words, etc.) so having only one method with
two strings is just very bad design.
Also if you read my mail I did talked about String based APIs but as
helpers and I'm would be surely -1 for any attempt to restrict the
whole API to it. So the only question here is: is that really needed
to expose String based helpers or not.
No, I was never suggesting to drop the generic API, I was just saying that
the helpers might be a good idea since I imagine that String diff would
cover most of the usage of this API. Anyway, this is not important for now
since it is something that can be added later if API clients start
complaining :)