Re: Tiger development Panther deployment
Re: Tiger development Panther deployment
- Subject: Re: Tiger development Panther deployment
- From: Frédéric BLANC <email@hidden>
- Date: Tue, 31 May 2005 16:07:01 +0200
On 5/30/05, Andy Lee <email@hidden> wrote:
> > Thx to keep your attention on the main issue…
> > or I won't give examples anymore :) ! (Just kidding…)
> :) Heh, sorry for digressing...
;) OK Andy, you've just been forgiven :) !
> Bob's answer makes the most sense to me for the general case of
> deprecated methods vs. possibly nonexistent newer methods.
Yep. (And thx Bob; I'll save your posts for the day I'll be full
Objective-C. Alas, I'm still englued into some Cocoa-Java projects for
the time being...)
> Check whether the object responds to the newer message, and if so,
> send it. In Objective-C, it's an extra two lines. The corresponding
> Java logic using reflection requires a bit more work, something like
> this (untested code):
And thanks Andy. I'll try to go this way soon (and I'll post my
results right here).
> This seems rather cumbersome compared to the Objective-C way, but I
> don't see how else to do it in Java. An alternative would be to
> build different .class files for Tiger and pre-Tiger, and decide at
> runtime which class file to load, but that's also cumbersome.
I agree. I think I'd better try your previous code instead :) !
> Checking for existence of individual methods is one backwards
> compatibility issue. There are also, obviously, entire frameworks
> and idioms you'd have to avoid to remain backwards compatible, like
> CoreData.
You're right. And that's also why I won't start any new project based
on Cocoa-Java :( ! I'm kind of frustrated not to be able to "play"
with the latest+"sexiest" frameworks/idioms Apple delivered through
Tiger; so my next project will be Cocoa-ObjC, that's for sure :) ! But
I simply have to support the current ones a little bit more...
Thx again Andy, Bob, et al.
--
— Frederic BLANC (email@hidden)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden