Hi there, firstly, glad to see this turning into a useful discussion...
On 06/01/2006, at 4:23 AM, Robert Walker wrote:
I personally tend to agree with Arturo. Yes it does take more discipline during development, but I consider that part of my job as a developer. It's vital to ensure APIs don't break with changes and bug fixes. If changes to API are necessary deprecate the old method, and create a new one to support the API change. The trick is in learning to recognize when a change affects the API.Taking a look at /System/Library/Frameworks and /Library/Frameworks you will see many frameworks written by Apple, and other software developers.
... and I usually try, if subclassing/extending their behaviour, to name my frameworks appropriately (e.g., LDJavaFoundation) so that it's obvious what they're doing in relation to the provided frameworks.
However, Cocoa and indeed WebObjects Frameworks can have multiple embedded versions (e.g., "A", "B", "C", "Current" --> "C")
i.e.,
MyGreatFramework.framework/
Contents/
Versions/
A
B
C
Current --> B
...
but there's no obvious way to link to a specific deployed version of
a framework (at least, within Xcode) within a WebObjects Application
as there is for a Cocoa app. The thing that this would enable is
either being able to deploy/depend on certain compatibility version
and/or testing a new version of a framework (e.g., version "C" with a
test app) prior to changing the Current symlink to point to "C" for
other apps to benefit (if applicable).
These frameworks are shared among many different applications. Those that make up parts of the OS share it's version number with the OS. Those that are specific to a developer application tend to be controlled by that particular application vendor.As WebObjects/Cocoa developers we should use this same approach. It seems to me the whole point of a "Framework" is to share its API with many applications. Otherwise, why separate code into a framework to begin with? (No intent to start a philosophical battle here. Just expressing my opinion.)
It's certainly the Object Oriented approach as it follows closely the concept of code-reuse, modularisation, abstraction and so on - and so it's the approach I naturally lean towards - but it has it's own set of trade-offs.
with regards, -- Lachlan Deck
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
