CoreDate (was: [Biococoa-dev] WWDC2005)
Alexander Griekspoor
mek at mekentosj.com
Thu Feb 17 15:23:00 EST 2005
> I do agree with Alex that KVC should be fairly easy to add. I also do
> like John's idea of sticking to 10.2 as much as possible, which should
> be possible with KVC. I also know that there are some differences
> which could get quite annoying, and that the 10.2 KVC is not as
> consistent and usable as the KVC in 10.3... but that may be fixable
> with some NSObject category. Anyway, after all these however/but, the
> bottom line is: my opinion is we should try to implement KVC asap and
> at the same time, stick to the 10.2 APIs as long as possible.
>
> Regarding other 10.3-sepcific APIs, here are the questions we should
> answer (in particular Alex):
> * Alex, what APIs other than binding are you refering to? Can we
> narrow down to just bindings the question of '10.2 vs 10.3'? Are there
> any other critical super-useful 1.3-specifc APIs that we are going to
> use? (e.g. NSIndexSet --> possible work-arounds)
> * Then, about bindings: are there really any use of bindings at the
> framework level? The bindings would be in the app, right? We would
> just have to be KVC-compliant in the framework. Do the bindings use
> 10.2 deprecated methods when forced to?
Ok, sorry but I was indeed specifically referring to a (future) appkit
side of the framework, not the foundation part (what we're working on
right now). This originated from the discussion about a demo app with
"webview" like view, that would really shine if it has binding support.
You're perfectly right that for the foundation (model) part we can
happily stick with 10.2 support, for bindings you indeed only need KVC
basically (which we implement already). The rest is in the controller
and view. I don't think that besides bindings there are many things we
can't do without in 10.3, that I can think of (like NSXMLParser, there
are plenty core foundation routines in 10.2 already).
The point was not to specifically start using all possible 10.3
options, but just to make the point that 10.2 support is not that
important anymore IMHO. Even if 5% sticks with it, that would not
justify refraining to advance/optimize our framework. But again, as
long as we can stick (if necessary with a bit of effort) to 10.2
compliancy in the foundation, that's a big plus of course.
If we go for an Appkit part (views etc) I would go for 10.3 from the
beginning though, primarily for the bindings part.
> NB: and yes, Koen, we should just be coding instead of chatting, for
> God's sake!
Sorry, yes boss, I'll see what I can do ;-)
Alex
>
> --
> Help science go fast forward:
> http://cmgm.stanford.edu/~cparnot/xgrid-stanford/
>
> Charles Parnot
> charles.parnot at stanford.edu
>
> Room B157 in Beckman Center
> 279, Campus Drive
> Stanford University
> Stanford, CA 94305 (USA)
>
> Tel +1 650 725 7754
> Fax +1 650 725 8021
> _______________________________________________
> Biococoa-dev mailing list
> Biococoa-dev at bioinformatics.org
> https://bioinformatics.org/mailman/listinfo/biococoa-dev
>
>
*********************************************************
** Alexander Griekspoor **
*********************************************************
The Netherlands Cancer Institute
Department of Tumorbiology (H4)
Plesmanlaan 121, 1066 CX, Amsterdam
Tel: + 31 20 - 512 2023
Fax: + 31 20 - 512 2029
E-mail: a.griekspoor at nki.nl
AIM: mekentosj at mac.com
Web: http://www.mekentosj.com
EnzymeX - To cut or not to cut
http://www.mekentosj.com/enzymex
*********************************************************
*********************************************************
** Alexander Griekspoor **
*********************************************************
The Netherlands Cancer Institute
Department of Tumorbiology (H4)
Plesmanlaan 121, 1066 CX, Amsterdam
Tel: + 31 20 - 512 2023
Fax: + 31 20 - 512 2029
AIM: mekentosj at mac.com
E-mail: a.griekspoor at nki.nl
Web: http://www.mekentosj.com
iRNAi, do you?
http://www.mekentosj.com/irnai
*********************************************************
More information about the Biococoa-dev
mailing list