Rename Material services to have $material prefixes

[btford]

With recent releases of Angular 1.3.x, $aria service conflicts with ngAria.
ngAria provides a $aria service, which collides with the $aria service in material.services.aria.

Is there a reason material design services are $-prefixed?

[ThomasBurleson]

@btford

As I recall, the intention was to identify Angular Material services with conformance to the naming conventions in Angular.

Since currently we only publish expectAttribute(), perhaps we can simply decorate the $aria service instance provided in ngAria ?

[ajoslin]

Could we not just make a utility function for expectAria?

[ajoslin]

Every service should be prefixed with $material - we could also do $materialAria.

[btford]

I think a decorator is the wrong approach. I'm going to go with @ajoslin's suggestion for now.

[ThomasBurleson]

No problem with $material (or $md) as service prefix as long as we are consistent.

[ThomasBurleson]

@btford Is the expectAttribute() functionality not something that $aria could use? Or is this a material-specific need?

[marcysutton]

That's actually a great idea @ThomasBurleson. It's a great way to gracefully add a label or other attribute. I could see something like it being very useful in ngAria. https://github.com/angular/material/blob/master/src/services/aria/aria.js

[btford]

we could move it to ngAria, potentially

[btford]

I addressed this for now with btford@1e13d58 in my PR.

It looks like the goal of this method is to provide a sensible default and also warn developers consuming the component that they may need to make a more informed decision. I like this, but it does add a few bytes to runtime. I think we may want to use a strategy similar to minerr but for warnings like this.

[marcysutton]

@ThomasBurleson @ajoslin is there more work to do on this or can I close it with #340?

[ThomasBurleson]

Also affected by planned efforts to use mt- prefix notations. @see #357

[marcysutton]

Renamed as of 3368c93