Expose internal headers

[maxep]

Move internal headers to private section.

[flovilmart]

@maxep thanks for the PR, what's the motivation behind it?

[maxep]

This allows to access private interfaces and utils that can be useful in an advanced integration of Parse. Public headers stays as is, but internal headers can used with an explicit import.

As an example, I've developed a module that can store Parse objects into Realm, to do so I need PFObjectPrivate, PFObjectState or PFMutableObjectState... I also make a good use of BFTask+Private, PFInternalUtils, PFHash, PFJSONSerialization..

It might be useful to others.

[flovilmart]

@maxep ok with the rationale, however, we can't really guarantee the stability of the internal headers, is that fine with you?

[maxep]

@flovilmart yes it's completely fine. Private headers are not intended to be used unless you know what you doing.

I can't find it anymore but Apple documention previously said:

Public: The interface is finalized and meant to be used by your product’s clients. A public header is included in the product as readable source code without restriction.

Private: The interface isn’t intended for your clients or it’s in early stages of development. A private header is included in the product, but it’s marked “private”. Thus the symbols are visible to all clients, but clients should understand that they're not supposed to use them.

Project: The interface is for use only by implementation files in the current project. A project header is not included in the target, except in object code. The symbols are not visible to clients at all, only to you.

[flovilmart]

Uhm ok, I need to clone your branch and check the list of headers that are exposed as private (vs internal) Do you think we could keep this list as minimal as possible and as powerful at the same time?

…

On Feb 5, 2018, 11:53 AM -0500, Maxime ***@***.***>, wrote: @flovilmart yes it's completely fine. Private headers are not intended to be used unless you know what you doing. I can't find it anymore but Apple documention previously said: Public: The interface is finalized and meant to be used by your product’s clients. A public header is included in the product as readable source code without restriction. Private: The interface isn’t intended for your clients or it’s in early stages of development. A private header is included in the product, but it’s marked “private”. Thus the symbols are visible to all clients, but clients should understand that they're not supposed to use them. Project: The interface is for use only by implementation files in the current project. A project header is not included in the target, except in object code. The symbols are not visible to clients at all, only to you. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[maxep]

Yes I will do that!

[flovilmart]

Thanks! @maxep I'd rather limit the exposure and add more over time than expose everything and risk breaking your components :)

[flovilmart]

@maxep not to put presure on you, I'd release 1.17.0 soon and it would be nice with this.

[maxep]

@flovilmart Ok I will try to push an update tomorrow :)

[maxep]

@flovilmart while it is easy to select private headers from the project targets, the current folder hierarchy makes it quiet complicated to specify them in the podspec.. I will need to reorganise the folders which can take some time and I don't know if you want to go in that direction?

[flovilmart]

Ah you’re right! This is quite tedious. I’ll check the branch and make sure it’s all clean, notably that the private headers are exposed to all targets.

[flovilmart]

I just closed and reopen in order for the CI to run

[flovilmart]

ALright let's go and see how it goes!