--- Neil Hodgson <nhodgson@bigpond.net.au> wrote:
> Thomas Heller:
>
> > In plain text:
> > Provide a method which returns a 'view' into your object's
> > buffer after locking the object. The view holds a reference
> > to object, the objects is unlocked and decref'd when the
> > view is destroyed.
>
> Yes, this handles the situation. However I see some problems here:
> 1 Explicit resource release, such as closing files, is easier to
> understand and debug than implicit ref-count exhaustion.
>
So add an explicit release() method to your object. Just because it
supports the "Fixed Buffer API" doesn't mean you can't add other methods to
it.
>
> 2 On platforms such as .NET and the JVM, the view object will live for an
> indeterminate time, prohibiting resizes until the VM decides to garbage
> collect. While the JVM can not return pointers, and so may seem to not be
> a candidate for this interface, it can return array references.
>
This is solved with the explicit release() method above. Just like files
solve this problem with an explicit close() method.
>
> 3 More complex implementation requiring a secondary view object.
>
It's also a more complex problem that you're trying to solve. Putting the
complexity on the common, simple, cases may not be appropriate when the
complex cases are few and far between.
Cheers,
-Scott
__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4