• 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: deprecated API
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: deprecated API


  • Subject: Re: deprecated API
  • From: Kieran Kelleher <email@hidden>
  • Date: Thu, 9 Feb 2006 22:23:21 -0500

Hi all,

I dunno if this qualifies as a best practice, but for every ivar I create in WOBuilder with the "Add Key..." contextual menu item, I start the name with an underscore and check the generate source code for getter/setter. WOBuilder automatically creates the getter and setter without the underscore, and the ivar is protected and begins with an underscore (I'm still on WO 5.2.3).

Another pain in the head for stateless manually synchronized reusable components is remembering to include new ivars in reset(), so some time back I created some functionality in a generic subclass for resuable components that automatically performs reset to null on any protected ivars beginning with an underscore. this complements creation of ivars beginning with underscore having setters/getters. It works really well and avoids the problems associated with forgetting to include newly created ivars in a reset method specific to every reusable WOCompent. It is also efficent in that the list of ivars that require resetting is created once only for each reusable WOComponent class.

The ugly details are here....
http://homepage.mac.com/kelleherk/iblog/C1133025376/E1146937278/ index.html


Great discussion, thanks, regards,

Kieran

PS. Chuck, when is the new book scheduled for amazon.com .... or even PDF purchase and download?!

On Feb 9, 2006, at 6:01 PM, Chuck Hill wrote:

Hi Art,

On Feb 9, 2006, at 2:44 PM, Art Isbell wrote:

On Feb 9, 2006, at 12:33 PM, Jerry W. Walker wrote:

Like Chuck, I tend to use straight assignment for many of the same reasons. However, in this example I just didn't want to make arbitrary decisions on whether the members whose values I was setting were iVars or methods.

Does it bother anyone else that WOBuilder generates protected rather than private ivars so that WO can access these ivars directly rather than using accessor methods? Seems like a bad practice to me.


Are they protected or public? I thought there were public in recent versions. But, yeah, it bothers me sometimes.


Instead, I make all my ivars private forcing WO to access them via accessor methods unless there's a good reason to make these ivars accessible to subclasses (but then they should probably use accessor methods also).

I'm not too overly strict in this area. If it is a binding (say item in a repetition) that I will never access in code, then I don't see the harm in making it public. Also, if it is a page (rather than a component that might get reused), I am a little less paranoid about public ivars that I don't (much) use in code. For anything that might get subclassed and reused, or which is used in code, I make the ivar private and add accessor methods.

Chuck

-- Coming in 2006 - an introduction to web applications using WebObjects and Xcode http://www.global-village.net/wointro

Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects




_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden


This email sent to email@hidden



_______________________________________________
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


References: 
 >deprecated API (From: zac <email@hidden>)
 >Re: deprecated API (From: Chuck Hill <email@hidden>)
 >Re: deprecated API (From: zac <email@hidden>)
 >Re: deprecated API (From: Chuck Hill <email@hidden>)
 >Re: deprecated API (From: Mike Schrag <email@hidden>)
 >Re: deprecated API (From: "Jerry W. Walker" <email@hidden>)
 >Re: deprecated API (From: Art Isbell <email@hidden>)
 >Re: deprecated API (From: Chuck Hill <email@hidden>)

  • Prev by Date: Re: deprecated API
  • Next by Date: WO, Java and Microsoft Active Directory
  • Previous by thread: Re: deprecated API
  • Next by thread: Re: deprecated API
  • Index(es):
    • Date
    • Thread