• 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: Extending NSKeyValueCoding?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Extending NSKeyValueCoding?


  • Subject: Re: Extending NSKeyValueCoding?
  • From: petite_abeille <email@hidden>
  • Date: Tue, 28 Oct 2003 11:17:12 +0100

Hi Anjo,

On Oct 28, 2003, at 10:15, Anjo Krank wrote:

Note that this class is mainly to provide access for protected fields/methods as they need to reside in the same package as the target. So they may or may not be invoked when using public methods.

Argh!

It may not help much, but Wonder now has a ERXMutableArray that implements the List interface (untested, it was write-only for now:). If you used EOF, then you could at least use this class when creating relationship arrays and wouldn't need to morph.

Thanks. I went down this road and I have even implemented some pretty funky bi-directional wrappers for both NSArray and NSDictionary... but... this is a mostly dead end.


If you used WO, then I have a (currently private) WORepetition that deals with List instead of Vector.

WORepetition is fine as it is as you can use the count/index binding instead of the list/item one. So that's alright.


And finally, I have bug report outstanding that NS* should implement the various Collection interfaces.

Yes. That's the only reasonable thing to do. If WebObjects doesn't play well with the java.util classes, it's pretty much a dead product as far as I'm concerned.


The argument given at WWDC 2000, when this first came up (null is not supported as a value or key in NS*) is moot anyway, as this is also not mandatory in the Collection contract.

Yea, whatever, all those funky Foundation classes have to go. There is no place for sentimentality in a toolkit.


Lastly, it would help a lot if NSKeyValueCoding.Utility was an object and not a class. Then one could extend it and re-set it to ones own subclass...

Yep. The default implementation of NSKeyValueCoding should be easily extendable. Oh, well...


In any case, thanks for the moral support :)

Cheers,

PA.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: Extending NSKeyValueCoding?
      • From: Anjo Krank <email@hidden>
References: 
 >Re: Extending NSKeyValueCoding? (From: Anjo Krank <email@hidden>)

  • Prev by Date: Re: Problem updating to WebObjects 5.2.2
  • Next by Date: Re: Extending NSKeyValueCoding?
  • Previous by thread: Re: Extending NSKeyValueCoding?
  • Next by thread: Re: Extending NSKeyValueCoding?
  • Index(es):
    • Date
    • Thread