[infinispan-dev] Separating FluentTypes into a separate file?

[Sanne Grinovero]

Hi Galder,
since it's not a public class I don't think that would be a problem;
in fact since the fluent configuration is relatively new maybe it's
better to break such things now than later.

On 12 October 2011 17:14, Dan Berindei <dan.berindei at gmail.com> wrote:
> Making a non-public type public preserves binary compatibility,
> according to http://wiki.eclipse.org/Evolving_Java-based_APIs_2#Achieving_API_Binary_Compatibility

I don't think that's related with Galder's question is it? Why do we
need binary compatibility? I think he's referring to APIs. Anyway the
classname is changing as well as it was a nested class so I don't
think it's preserving binary compatibility.

Cheers,
Sanne


>
> Cheers
> Dan
>
>
> On Wed, Oct 12, 2011 at 5:28 PM, Galder Zamarreño <galder at redhat.com> wrote:
>> Hi,
>>
>> Would it cause any problems if FluentTypes class in FluentConfiguration was separated into a separate file? i.e. backward compatibility issues.
>>
>> Remember that FluentTypes is not a public interface per se, and it's not something clients would reference directly.
>>
>> The reason I want to change this is cos it causes all sorts of access issues when you try to use fluent configuration from Scala.
>>
>> If it can be problematic, no probs, I'll wait for 6.0 to separate this class into a separate file and Scala can carry on with old configuration.
>>
>> Cheers,
>> --
>> Galder Zamarreño
>> Sr. Software Engineer
>> Infinispan, JBoss Cache
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>