Cool, thanks for the explanation, you make good points. So yeah, +1 on the
change as i can;t think of any higher level use case and it does make the
contract more understandable, and easier to implement.
On Sun, Apr 15, 2012 at 6:02 PM, Gabriel Roldan <[email protected]> wrote:
> On Sun, Apr 15, 2012 at 6:43 PM, Gabriel Roldan <[email protected]>
> wrote:
> >> Well the fact that test assertions are being changed sort of means
> there is
> >> a use case :)
> There is in the test cases. I started asking what the "real world" use
> case is. If we are "fixing" the method contract, it makes sense to fix
> it's test expectations accordingly (the unit test is checking the
> class does "things right", but does it do "the right thing"?). So
> yeah, back to the original question, I am not sure if this is "fixing"
> at all, cause I'm not sure if there's some higher level use case
> depending on it? It looks to me like there isn't, but as didn't design
> the API I can't be sure. If the current behavior _is_ needed I'm more
> than willing to stop wasting everybody's time (and refrain from
> argumenting the API keeps being confusing).
>
> Cheers,
> Gabriel.
> --
> Gabriel Roldan
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
