So the framework.m files are online somewhere?
Or are they already partially integrated into the compiler and automatically implemented during test runs, somehow?
iMac
Or are they already partially integrated into the compiler and automatically implemented during test runs, somehow?
iMac
If you're referring to '.m' files other than those you've created yourself, only the party that created them has the source.
The methods defined in the '.m' files are defined in the publicly available '.h' files which is how we can make use of Apple and third party libraries.
If you're referring to '.m' files other than those you've created yourself, only the party that created them has the source.
The methods defined in the '.m' files are defined in the publicly available '.h' files which is how we can make use of Apple and third party libraries.
I have four questions about that.
First, how does the compiler test run make use of the .m files if they are not publicly available?
Second, what is the benefit to the party that created the .m files of owning the source to them?
Third, doesn't Apple own the available Cocoa framework classes and methods?
Fourth, if I make a class out of different Cocoa classes, is that then my copyright?
1. The object code created by the compiler is publicly available if free or for a price if not.
2. Would you want to give away the source to your best-selling app?
3. Yes.
4. See a copyright lawyer. (However, I think anything one creates is automatically copyrighted as original work).
mark133 wrote:
First, how does the compiler test run make use of the .m files if they are not publicly available?
Linker and runtime magic.
Second, what is the benefit to the party that created the .m files of owning the source to them?
People like to own their stuff.
Third, doesn't Apple own the available Cocoa framework classes and methods?
Certainly
Fourth, if I make a class out of different Cocoa classes, is that then my copyright?
Yes
I guess 'runtime magic' will have to do. Maybe 'it's somewhere in the OS cosmos'? Good enough for me.
Check out RuntimeBrowser
I'm all for new product, but isn't this the manual? But it looks like when you click on the .h file, instead of the image on the right, being the actual .h file, you get a nice convenient listing in the same format you are used to working with. Plus it saves you the time of looking up the manual page. Am I understanding how to use RuntimeBrowser? Is there a demand for this?
I'm actually getting a headache right now trying to make these three images fit into one common understanding of the form. I still haven't used a library class successfully. Well, to be fair I haven't really tried yet. I want to do myself whatever favors possible in the planning stages. After all, the result is the sum of the planning.
So right now, I'm planning how best to interact with and use any one particular class, and therefore any class in general. Do you think this RuntimeBrowser would be a time-saving tool for me in the near future?
Are these three different versions of the same class in the three images? It seems so to me right now.
That looks like a lot of very interesting, very creative people. In almost every art, I've found that producing something marketable comes down to discipline and designing for others with a key, but limited role for self-expression.
RuntimeBrowser is just a hacking tool to help explain how the "Runtime Magic" works.
Do you mean a hacking tool, a hacked tool, a tool for hackers, or a tool for hacks?
If you mean a tool for hacks, that might apply to me, but my intention is to grow beyond that.
The design of these products and security of keeping the core functions seperated from the users is great. I have no problem with that whatsoever. The fact that so many people have been involved with designing a system that is inaccessible to the public, while at the same time going to all the double trouble and effort of making the essence of the tools more and more accessible to the public, is awesome.
mark133 wrote:
Do you mean a hacking tool, a hacked tool, a tool for hackers, or a tool for hacks?
Yes
The design of these products and security of keeping the core functions seperated from the users is great. I have no problem with that whatsoever. The fact that so many people have been involved with designing a system that is inaccessible to the public, while at the same time going to all the double trouble and effort of making the essence of the tools more and more accessible to the public, is awesome.
I don't quite understand that. It is standard procedure to define a limited public interface for 3rd party developers to use. That interface needs to be stable, reliable, and useable for years. You don't want people's software to suddenly stop working because you changed the API. Apple will not change a public API without several years advance warning.
The internal code is a different matter altogether. It can, and does, change frequently to add new capability will still maintaining the old interfaces. If you aren't selling in the App Stores, then you can use those private APIs if you enjoy living dangerously.
I don't enjoy living dangerously. I've done enough of that already. Now I'm married with children and extremely risk averse.
I mean Apple goes to great lengths to not only make the more fundamental tools available to the public (which is necesarily contrary to the need for security) but excels at it and at encouraging the public to use the tools. That's very different from some companies who prefer an approach that limits use to certain classes of people, and only if they are connected with certain institutions, etc.
Of course, that's the essence of Apple, and the spirit that launched the original Apple computer...making the technology non-exclusive, publicly available technology while absolutely securing the system in its essence. Very American approach to having an advantage (while doing everything possible to make that advantage available to all).
So the framework.m files are online somewhere?