Move depracted? method from Presenter to a DSL helper in specification

[k0nserv]

I realised that it doesn't make much sense to have this logic in the presenter when I was looking at the implementation of https://github.com/CocoaPods/search.cocoapods.org. If you agree with this move I'll update the change I made to https://github.com/CocoaPods/CocoaPods

[fabiopelosin]

It should be moved to https://github.com/CocoaPods/Core/blob/master/lib/cocoapods-core/specification/root_attribute_accessors.rb (because the spec class is too bloated and it is a root attribute).

[k0nserv]

Okay. I put it as a DSL helper because in reality it's a combination of two root attributes, from reading the root attribute code it looked like it was just doing mapping without any logic. I also think there could be a problem with having both deprecated and deprecated? because they are not distinct. is_depracted? is slightly better for the name, but still a bit undescriptive

[k0nserv]

Ping @irrationalfab any comments on my last comment?

[fabiopelosin]

from reading the root attribute code it looked like it was just doing mapping without any logic.

There is some logic in some attributes: https://github.com/CocoaPods/Core/blob/master/lib/cocoapods-core/specification/root_attribute_accessors.rb#L49. Although you are correct to say that the all methods mirror the attributes. However it is more important to group root attributes there than to adhere to the above observation.

I also think there could be a problem with having both deprecated and deprecated? because they are not distinct. is_depracted? is slightly better for the name, but still a bit undescriptive

is_depracted? is not a candidate, because in Ruby the final question mark means is_.

What I would do is: move the stuff to the root attribute accessor because all the root attributes are grouped there (this is not the state of the art of software architecture but until is refactored this is the logic). There should be two methods there deprecated? (returns if the Pod is deprecated, regardless of how the deprecation was specified which is not interesting to clients) and deprecated_in_favor_of (which returns nil if there is not an alternative Pod).

This is my take.

[fabiopelosin]

I have rebased and merged this patch via 1be2e4e. Thanks @k0nserv!