Hi Shaun,

On 25/11/2005, at 11:17 AM, wojingo wrote:

I'm curious. Why would you call takeValueForKey rather than a set method? If you have no set method then why not just set the variable directly? ie) aSurvey.dateOfLastChange = new NSTimestamp();

Your implementation above is not providing any compile-time checking on setting of dateOfLastChange. If you accidently typed dateOfLastChage you won't know about it until the code executes.

Welcome to the world of dynamic vs static typing wars...
Bring back Objective-C WO as an option I say  :-)

Instead of using a "specificStringKey", utilising a final static string will do the job nicely. That way you've written it once and reused it, and if it needs to change, you change it once.

Seriously, there are a lot of advantages to utilising takeValueForKey instead of static typing. Have a read of the NSKeyValueCoding interface API for starters. Automatic type conversion, field accessing and generally being more immune to specific knowledge of implementation details and so on. Even better, utilising NSKeyValueCoding.Utility.[take]ValueForKey.

The Key-Value-Coding camp doesn't care (or need to know) the specific implementation details of the other class - that's their problem. We just want to interact with their generic interface.

public class SomeClass implements NSKeyValueCoding {
        public static final String TimeStampKey = "timestamp";
        ...
}

e.g., nextPage.takeValueForKey(anObject, SomeClass.TimeStampKey );

If they choose to implement the method as any of the following, the above line will work:
public void _setTimestamp(NSTimestamp stamp) {}
public void setTimestamp(NSTimestamp stamp) {}
NSTimestamp _timestamp;
NSTimestamp timestamp;

and so on...

Now extend that logic and imagine you've got an NSDictionary of objects to update an instance of _any class_ with:
public class Application extends WOApplication {
public void updateValuesForInstance(NSDictionary values, Object anInstance) {
                Enumeration en = values.keyEnumerator();
                while ( en.hasMoreElements() ) {
                        String aKey = ( String )en.nextElement();
                        Object anObject = theObjectsPerKey.valueForKey( aKey );
NSKeyValueCoding.Utility.takeValueForKey( anInstance, anObject, aKey );
                }
        }
}

Now notice that we didn't need to care about type casting and all that nonsense when passing the objects - and we've got a well-tested reusable method that will save many a line of code elsewhere (where static typing would have been used). NSKeyValueCoding correctly casts the objects for you. Well, to my way of thinking it lends itself towards writing less code, code that's less susceptible to specifics, code that's more reusable, etc...

Certainly compile-time error checking has good value. So the developer has to decide about the kinds of trade-offs they're willing to live with... usually a mixture of the two.

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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to