• 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: Using runtime functions to match up object types safely when setting properties
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using runtime functions to match up object types safely when setting properties


  • Subject: Re: Using runtime functions to match up object types safely when setting properties
  • From: Ken Thomases <email@hidden>
  • Date: Fri, 19 Dec 2008 21:28:51 -0600

On Dec 19, 2008, at 6:53 PM, Graham Cox wrote:

In my app, I have an interface and code that allows the user to set up different values that can be set as properties of an object. The user is presented with a list of properties that can be set (suitably converted for display in the UI) and then they can set up the values of these properties, which can be one of five distinct types (a custom type, an image, colour, string or numeric value).

I'd like to be able to gently prevent the user from making an inappropriate choice. For example if the given property expects a string, they should not be able to choose an image object.

First of all, are you familiar with Key-Value Validation? http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/KeyValueCoding/Concepts/Validation.html


So I'm looking for a way to safely and reliably determine whether a property will accept an object of a given type. I wrote this category on NSObject as a simple wrapper on the runtime to attempt this, but it doesn't work quite how I expected - any property that returns an object simply returns '@' as its return type - I can't tell what class it is. Can anyone point me in the right direction?

I don't believe this is possible. The "@" you're getting is the type encoding for an object pointer.


http://developer.apple.com/documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Articles/chapter_7_section_1.html

Note how it says "whether statically typed or typed id".

Basically, in Objective-C static typing is purely a compile-time thing. The compiler can use it to check the semantics of your program. However, it's "lost" after that. It's not baked into the resulting executable. Therefore, the Objective-C runtime can't access it. It just isn't there.


I think your only avenue is to implement explicit KVV methods for your properties which have the necessary knowledge to test their type. I suppose you could file a feature request to extend declared properties so they can synthesize a type-checking validation method. Or request a compile-time directive to determine the static type of a method return or a property. (Hmm. gcc has a "typeof" extension. I wonder if it works in Objective-C.)


Good luck,
Ken

_______________________________________________

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: Using runtime functions to match up object types safely when setting properties
      • From: Andrew Farmer <email@hidden>
    • Re: Using runtime functions to match up object types safely when setting properties
      • From: Graham Cox <email@hidden>
References: 
 >Using runtime functions to match up object types safely when setting properties (From: Graham Cox <email@hidden>)

  • Prev by Date: Re: Drawing in a NSView out side of drawRect
  • Next by Date: Re: Using runtime functions to match up object types safely when setting properties
  • Previous by thread: Using runtime functions to match up object types safely when setting properties
  • Next by thread: Re: Using runtime functions to match up object types safely when setting properties
  • Index(es):
    • Date
    • Thread