I agree

So the recommended way of getting service by name will from 4.00 be ClassName::class as the IDE will help greatly there will be less typing however overriding/decorating the services will be annoying as the name won't represent the actual class anymore but the name itself will suggest that. ATM the service name could be seen as some kind of alias.

P.S. also service names will be longer I'm wondering how much more RAM will the cached DIC require and also if those strings go into the interned string cache the cache might become to small the default which is 4M might be to small even today

@mvrhov we don't enforce using class names as id (it would break many use cases, as being able to replace an implementation is a great use case).
But we are making the id optional, using the class name in this case, to keep things simpler for newcomers.

Then the above doesn't make much sense (ok, it does, if the service name is class name). AFAIR the we switched once before to CI ones.

I don't understand your answer

Would doing the same for parameters be relevant?

@chalasr I don't think so. I mean, deprecating for ids has first technical reason, which is doing more inlining, thus perf. For params, unless you can envision one, there is no such gain.