Remove 'I' prefix from primitive interfaces in MBrace.Core?

[eiriktsarpalis]

So MBrace.Core comes with many primitives that are essentially interfaces. Following .NET convention, these are named using the 'I' prefix; for instance ICloudValue, ICloudDictionary, ICloudAtom, etc. I think it would make sense to discard the prefix, since the fact that these are interfaces hardly matter to the MBrace end-user, he should not be implementing them in any case. Thoughts?

[palladin]

I don't think that we have any particular reason to remove the 'I' prefix ... Coming from a Java background makes sense but for OSS .net project it is best to follow the conventions and practises. I'll really like to know @dsyme's opinion on this issue.

[isaacabraham]

I've gone through both sides of this. Most people stick the I in front, even though IMHO this is just cargo cult and is often worthless. However, if that's what everyone does, there's probably value in keeping with it.

I've been on projects where I've removed the I at the front (especially when the concretes aren't public) but people still moaned about it - it's so deeply ingrained in .NET developer's mindset. The AWS SDK also started without the I and then added them in later on for (as far as I understand it) this very reason.

[eiriktsarpalis]

I believe that the 'I' in interfaces conveys an intent of arbitrary, pluggable implementation by the consumer of the API. However, a user of MBrace should not be providing his own implementations of CloudValue; these are given by the runtime implementation. The use of interfaces here is incidental, these might have well been abstract classes. This is already true for CloudFlow<'T>, which is actually an interface. The omission of the 'I' prefix nicely obscures what is really an implementation detail.

In general, MBrace abstracted primitives come in pairs. For instance you have ICloudValue and ICloudValueProvider, much like the factory pattern. The former lives in the MBrace.Core namespace while the latter lives in MBrace.Core.Internals, which restricted to runtime implementors. My suggestion here is to adopt the naming convention CloudValue/ICloudValueProvider, CloudAtom/ICloudAtomProvider, etc.

[isaacabraham]

Wouldn't that be cloudvalue / cloudvalueprovider (without the I)?

[eiriktsarpalis]

No. Point being the latter is an interface in the full sense, meant to be implemented by people that create MBrace runtimes.

On Tue, Jul 21, 2015 at 09:43 Isaac Abraham notifications@github.com wrote:

Wouldn't that be cloudvalue / cloudvalueprovider (without the I)?

— Reply to this email directly or view it on GitHub https://github.com/mbraceproject/MBrace.Core/issues/111#issuecomment-123187443 .

[dsyme]

FWIW, when using Mbrace I assume I can just ignore all the interfaces and only look at types Cloud*.

The exceptions are that I see uses of ICloudAtom, IReceivePort and ISendPort - the former feels like it should just be CloudAtom, the latter pair I have suggested become CloudQueue.

[dsyme]

I don't really mind if interface types don't have "I". I do mind if the API requires knowledge of any I* named types for beginner scenarios :)

[eiriktsarpalis]

This has been changed in the master branch. Closing this.