On 01/29/09 13:51, "Christiaan Hofman" <cmhof...@gmail.com> wrote:

> On 29 Jan 2009, at 7:56 PM, Maxwell, Adam R wrote:
> 
>> On 01/29/09 09:21, "Christiaan Hofman" <cmhof...@gmail.com> wrote:
>> 
>>> Anyway, the check as it is currently shouldn't be necessary.
>> 
>> Only for autocomplete, as I was surprised to find.
> 
> Also when it's not appearing in the Editor?

I just meant I was surprised to see that Bdsk-File fields were being added
to the autocomplete dictionary, over a year after the feature was added.
That was probably wasting a fair number of bytes on a large file (I think
that would be the only retain on the base64 strings).
 
>>  I had to add that case
>> in the parser because I'm using openssl for base64 instead of Omni's
>> decoder, and it seems to be stricter about line breaks and spaces.
> 
> Good to know, as I've also added that to Skim. Though not in any way
> where this could be a problem.
> 
>> Which
>> wasn't a problem until I sent a message to myself from work using
>> Entourage.
>> I don't recall why I used openssl in the first place...a quick
>> glance at OF
>> tells me that I was probably trying to avoid temporary objects.
>> 
>> Actually, I think it would be cool to eliminate the Omni frameworks
>> entirely, although the preferences window alone makes that a really
>> daunting
>> task.
> 
> Yea, there's a lot of stuff in it I really don't like. Such as
> implementation overriding Leopard API and far too many swizzling.

Those are exactly my complaints.  Swizzling and categories are everywhere,
and the combination can lead to a fair number of unpleasant surprises.  I've
been trying to minimize category usage in new code, and I really haven't
missed them.

Since NSUserDefaults is thread safe, one of the advantages of OFPreferences
is eliminated.  And I won't even start on OAApplication and its sheet queue
or OFController and the way they've screwed up exception handling for
Leopard.

> But indeed it would be a lot of work to change everything. As for the
> pref window, I believe there's also alternative implementation for
> that alone (though I don't know how good they are).

SS_PrefsController looks reasonable:

http://mattgemmell.com/source

Uli Kusterer has one, and Andreas Mayer has one that looks like Omni's.
Maybe everyone writes his own because there are no good implementations :).
 
> Talking about that, when I was looking into the runtime implementation
> to improve method swizzling in Skim I was really surprised that the
> old runtime system wasn't thread safe!  Only in 10.5 did they add
> locks, but not everywhere. And Omni's implementations were originally
> using the thread-unsafe stuff even on Leopard (that's changed now).

Interesting.  I'm a bit surprised that they use locks now, since I'd expect
that to be a pretty significant hit.  Cocoa is still full of thread safety
surprises too...like the NSTask class being unsafe to use in a background
thread.  Or the font server trashing its internal state and deadlocking.

Speaking of runtime, I've been happy using for/in, @property and
@synthesize, although I've never tried garbage collection.  It's too bad
zero cost exceptions and synthesized storage are only available in 64 bit,
since there are still a lot of G4 systems out there.



------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Bibdesk-develop mailing list
Bibdesk-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop

Reply via email to