>> 3.6 cocoa is better, but still has performance problems. I'm still debating about what my plan will be here.
> Will there be a Carbon version? 3.5 Carbon is pretty fast, and neither version looks like a real Mac application. So I guess the only difference is that not all plug-ins work with the Carbon version (e.g. JD-Eclipse doesn't seem to work).
WOLips doesn't have carbon vs cocoa dependencies (though Maclipse does). The cocoa one has slightly better fidelity to native controls, but only in subtle ways. SWT's job is to mostly hide platform differences from you, so a properly behaving SWT would not reveal any difference between Cocoa and Carbon. The reality is that some differences leak through. But the intent of cocoa vs carbon eclipse is not for one to look better than the other, it's more about moving the platform forward. With Carbon UI only supporting 32bit, the only path to 64bit with Eclipse was to go to Cocoa. The reality is that it probably won't help things all that much (even with a faster VM, I find I'm usually IO-bound in eclipse rather than CPU-bound).
On the Maclipse, front, we have to pick Carbon or Cocoa. I don't know what the plan is here. Just when I think I want to suck it up and go Cocoa, I run into something that turns me off, but sticking with Carbon means yet another port to a dying platform. Cocoa SWT just can't seem to get it all together on the performance front.
>> Personally, I don't turn off that warning because it punishes you for doing potentially bad things.
> Do you still have code that is not parametrized? I think using generics is the Java way to do things, so I always parametrize my NSArrays/NSDictionaries.
Almost all my personal code is parameterized, but there are some cases with generics that you just can't resolve without doing inefficient things (like making copies of collections) whereas you can actually do a cast to work around problems. For instance, taking advantage of the fact that you're returning an immutable array type allows you to safely cast up the generic inheritance tree without recreating the collection. There are also a bunch of API's down inside of EOF that aren't generic, and require casting -- objectsWithFetchSpecification, for instance, can't be made properly generic because that single API can return NSDicts or EO's. It's pretty hard to actually remove all warnings without @Suppress'ing some of them (unless you turn it off, like you pointed it). I just don't like to turn it off.
> However I noticed that NSMutableArray's addObject() is not parametrized.
Pretty unfortunate ... That's one of about 15 generic transgressions in 5.4's collections. I don't remember if we made addObject generic in Wonder's build. It's generic in later WO's.
>> I try and eliminate the warnings by fixing the code, but sometimes that is not practical.
> For example? So far I haven't come across that case.
see above :)
>> Adding a..uppressWarning is grating enough to not be something I do lightly.
> I just noticed that quite soon every class gets annotated with it (even in not so big projects) so it just becomes noise that you no longer see.
I think this is just a personal preference / religious thing, particularly with the generics-related warnings.
ms
This archive was generated by hypermail 2.0.0 : Wed Apr 07 2010 - 14:56:12 EDT