Re: Mutable/non-mutable bindings in NSTextView
Re: Mutable/non-mutable bindings in NSTextView
- Subject: Re: Mutable/non-mutable bindings in NSTextView
- From: Greg Herlihy <email@hidden>
- Date: Sat, 25 Feb 2006 17:48:54 -0800
- Thread-topic: Mutable/non-mutable bindings in NSTextView
I think a log could be well-suited for bindings, but not by modeling the
entire contents of the log as a single attribute. Since the entire, existing
log has to be copied each time a new entry is added, the expected
performance of adding an entry will degrade linearly, in direct proportion
to the size of the log. So doubling the size of the log would approximately
also double the amount of time it takes to add a new entry.
Now the linear performance of adding entries may never become an issue: the
log may never grow large enough, or current machines may be fast enough to
keep up with a log that grows to a reasonable size. On the other hand, Cocoa
bindings enable an app to attain better performance in this situation and at
the same time to offer the user much more capability to examine and
manipulate the contents of the modeled data (the log, in this case).
Modeling the log as a collection of individual log entries, instead of as a
single attribute value, delivers both superior performance and a more
dynamic presentation. In this model, each log entry would contain certain
attributes in common: such a timestamp, message text, perhaps a level of
importance - whatever makes sense for the log. A table could then be used to
display the entries, with each row in the table corresponding to a single
log entry. Presenting the information in a table, allows the user to sort
them by timestamp (for example, to show the most recent entries at the top
of the list instead of the bottom) or by other criteria, to filter entries,
to search for entries, or to delete entries on a one-by-one basis.
Unlike the single attribute model whose performance can be expected to
decline at a linear rate, the multiple entries model's performance will
decline at a much more gradual rate: in logarithmic proportion to the number
of existing entries. The primary reason for the better performance derives
from the fact that value attributes are represented by constant objects,
while to-many relationships employ a mutable set or array of objects. So
with the log modeled as a collection of entries, it is possible to add new
entries to the log without having to copy and replace all of the log's
existing entries as well. Therefore the amount of time needed to add each
new log entry grows at a steady rate even as the number of entries keeps
doubling in number.
Greg
On 2/25/06 10:06 AM, "Camillo Lugaresi" <email@hidden> wrote:
> On 25/feb/06, at 17:22, David wrote:
>
>> Yes, I missed that key step. Thanks. I've found that I can also
>> use willChangeValueForKey and didChangeValueForKey then do the
>> regular release and new allocation.
>>
>> Since I will be continuously updating the NSTextView contents
>> programmatically as well, it appears I will have to do something
>> like:
>>
>> [self willChangeValueForKey:@"log"];
>> NSString *newLogContents = [[log stringByAppendingString:@"more
>> contents added"] retain];
>> [log release];
>> log = newLogContents;
>> [self didChangeValueForKey:@"log"];
>>
>> Is this correct approach?
>
> I wouldn't use bindings for the contents of a log, unless updates are
> infrequent and it's limited to a very short length.
>
> Camillo
> _______________________________________________
> 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
_______________________________________________
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