Re: Frameworks and versioning
Re: Frameworks and versioning
- Subject: Re: Frameworks and versioning
- From: Lachlan Deck <email@hidden>
- Date: Fri, 6 Jan 2006 06:00:01 +1100
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden