• 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: Future Objective-C changes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Future Objective-C changes


  • Subject: Re: Future Objective-C changes
  • From: Marcel Weiher <email@hidden>
  • Date: Wed, 21 May 2003 15:54:31 +0200

Actually I'm "defining" a local variable,

Gosh, this sure looks like a declaration to me, and just strengthens my point. How can I tell the difference by looking at the code? How is the code intention-revealing?

void foo()
{
//These are all defining local variables:
int i;
float f;
MyClass c;
}

Sorry, this has been called *declaring* local variables as long as I can remember. However, I don't really care...

//These are declaring variables:
extern int i;
extern float f
extern MyClass c;

For globally scoped variables, there is actually a difference, for locals there is not.

and a defining local variable is nothing more than attaching some bit of data to the local stack frame, so it has *everything* to do with the local stack frame.

Exactly! *Declaring* the local variable has something to do with the *local stack frame*. It has NOTHING whatsoever to do with modifying *global* state.

It does,

That is the point: it does not.

if I want to ensure that the global state will be restored upon exiting the local stack frame.

Yes: *if*. However, I will maintain that 'wanting' to tie the global to a 'stack frame' is already a translation of what you actually want to do, which has nothing to do with stack-frames whatsoever. You want to do some specific drawing without impacting the current gstate, which is why you surround it with gsave/grestore.

That is the whole point ot such a class: to tie the restoration of the global state, or the release of some resource to the local stack frame.

Try to separate implementation from intent. And then try to see how your original intent is expressed in a readable fashion in the code.

It is simply good practice to make sure that a function will clean up after itself in all foreseeable cases.

It would be even better if the environment were put together in such a fashion that this weren't necessary.

On the other hand, the global graphics state has nothing to do with the local stack-frame.

That is why such a class is so useful.

Nope. The fact that you find this tying useful is a code smell: your code is trying to tell you that something is wrong. You can either put air-freshener over it or fix the cause of the smell.

Marcel


--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: Future Objective-C changes (From: "Clark S. Cox III" <email@hidden>)

  • Prev by Date: Re: Future Objective-C changes
  • Next by Date: Re: Future Objective-C changes
  • Previous by thread: Re: Future Objective-C changes
  • Next by thread: Re: Future Objective-C changes
  • Index(es):
    • Date
    • Thread