Composed names on services is not a good idea. about satellizer HOT 7 CLOSED

It is fine. I have given it much thought and looked at plenty of style guides and examples regarding namespacing so this is not too uncommon. Since I am no longer using ngAnnotate I have to inline annotate anyway.

Anything prefixed with satellizer. is not meant to be extendable or overridable, it is for internal usage only. Once AngularJS 2.0 comes around I will make all those services private.

from satellizer.

Alright, as always I respect your decisions, I just point out things that are more weird. I never saw that namespacing tbh and I done a lot of angular so far.

Leave it as is then, if it is not mean to be decorated by end users, good enough :)

from satellizer.

You might be right, I may have confused it with module namespacing notation, which is very common. Either way it's just an internal implementation detail.

We can discuss whether to keep it or switch to camelCase later, after all primary issues are fixed.

from satellizer.

Yes, module notation is different, but yes, let's talk about that after things are fixed.

from satellizer.

@Foxandxss If I namespace each service into its own module called satellizer.popup for example, and then require it in the main satellizer module like so:

angular.module('satellizer', ['satellizer.popup']);

Will satellizer.popup module be private if someone includes the main satellizer module in their app?

angular.module('MyApp', ['ngResource', 'ngMessages', 'ngRoute', 'satellizer', 'mgcrea.ngStrap'])

from satellizer.

no, it will be "public", so i can use it like:

angular.module('foo', ['satellizer.popup'])

can't really see how that causes an issue, tho :-)

from satellizer.

The thing is, why you need private? You don't. People will still inject "satellizer" to use the library, but if they need to inject the other inner services for something, let them do it!, You shouldn't restrict what they can do.

from satellizer.