• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: File Extensions Problem
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: File Extensions Problem


  • Subject: Re: File Extensions Problem
  • From: "R.L. Grigg" <email@hidden>
  • Date: Wed, 27 Aug 2008 15:59:12 -0700


On Aug 27, 2008, at 12:19 PM, Ken Thomases wrote:

On Aug 27, 2008, at 1:50 PM, R.L. Grigg wrote:

This is interesting. Correct me if I'm wrong but as a newb what I'm getting from all this is if I design my code around implementation specifics of frameworks or even the language I'm using, that equates to a unrobust design, cuz if the underlying implementation changes, I'm screwed, whereas simpler, more bread-and-butter "textbook" designs are much more likely to weather any underlying implementation changes, sort of like keeping your design at a high level and not dirtying it with low-level implementation specifics.

Is that a reasonable conclusion to draw?

The framework provides a contract as part of its public interface. The contract specifies what responsibilities you have and what responsibilities the framework has. Turning that around, the framework has the right to expect you to uphold your responsibilities and you have the right to expect the framework to uphold its responsibilities. Neither of you have the right to expect more than what's in the contract.


In other words, you should pay no attention to the implementation details, which are defined as those things which aren't specified in the contract.

The framework designers try to keep their declared responsibilities as unrestrictive on them as is reasonable, given that they want to provide a useful framework. The freedom that this gives them allows them to alter the implementation details, perhaps to improve performance or enable new features, but also perhaps just to make life easier for them, speeding development of the framework.

Hmm, I guess the wrinkle in this particular case is if the "contract" doesnt specify something that the programmer assumes to be safe to do (like enumerating backwards), how can you know how to implement your end? I guess there are times when the underlying implementation details can/must influence your highlevel design?


Thx,
Russ

_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: File Extensions Problem
      • From: Ken Thomases <email@hidden>
    • Re: File Extensions Problem
      • From: "Michael Ash" <email@hidden>
    • Re: File Extensions Problem
      • From: Phil <email@hidden>
References: 
 >File Extensions Problem (From: Adil Saleem <email@hidden>)
 >Re: File Extensions Problem (From: Michael Dautermann <email@hidden>)
 >Re: File Extensions Problem (From: Andrew Merenbach <email@hidden>)
 >Re: File Extensions Problem (From: Graham Cox <email@hidden>)
 >Re: File Extensions Problem (From: Phil <email@hidden>)
 >Re: File Extensions Problem (From: Graham Cox <email@hidden>)
 >Re: File Extensions Problem (From: "Michael Ash" <email@hidden>)
 >Re: File Extensions Problem (From: Thomas Engelmeier <email@hidden>)
 >Re: File Extensions Problem (From: "R.L. Grigg" <email@hidden>)
 >Re: File Extensions Problem (From: Ken Thomases <email@hidden>)

  • Prev by Date: Re: File Extensions Problem
  • Next by Date: iphone SDK questions
  • Previous by thread: Re: File Extensions Problem
  • Next by thread: Re: File Extensions Problem
  • Index(es):
    • Date
    • Thread