On Apr 12, 2008, at 08:36, Alastair Houghton wrote:
or even
-(void)discard;
Anyone have any preferences? I quite like -discard.
"discard" sounds so ... cruel. :)
"surrender"?
"derez"? (j/k)
How about "unleash"? That also contains a verb which could be used to
describe the overall tec
On 11 Apr 2008, at 18:27, Quincey Morris wrote:
On Apr 11, 2008, at 09:51, Alastair Houghton wrote:
It doesn't, but you might conceivably have methods that take an
NSEnumerator and do something with the objects it returns. Hence
the utility of "nextObject".
Ah, I see - simultaneous cake-
On Fri, Apr 11, 2008 at 4:15 PM, Michael Ash <[EMAIL PROTECTED]> wrote:
> I think it's inherently not possible to do without destroying the
> speed you're trying to gain. Due to how Apple's collector is
> implemented, not generating write barriers for stack values, seeing if
> an object has be
On Fri, Apr 11, 2008 at 12:53 PM, Alastair Houghton
<[EMAIL PROTECTED]> wrote:
> On 11 Apr 2008, at 16:07, Michael Ash wrote:
> > On Fri, Apr 11, 2008 at 6:04 AM, Alastair Houghton
> > <[EMAIL PROTECTED]> wrote:
> >
> > > Under GC, these kinds of tricks are no longer possible because there is
> no
On Apr 11, 2008, at 10:25 AM, Buddy Kurz wrote:
I'm wondering if it would make sense (or be possible) to override -
retain and -release to increment/decrement your own variable in
addition to using the inherited behavior. In the GC environment,
the inherited retain does nothing but in eith
Le 11 avr. 08 à 19:27, Quincey Morris a écrit :
On Apr 11, 2008, at 09:51, Alastair Houghton wrote:
It doesn't, but you might conceivably have methods that take an
NSEnumerator and do something with the objects it returns. Hence
the utility of "nextObject".
Ah, I see - simultaneous cak
On Apr 11, 2008, at 09:51, Alastair Houghton wrote:
It doesn't, but you might conceivably have methods that take an
NSEnumerator and do something with the objects it returns. Hence
the utility of "nextObject".
Ah, I see - simultaneous cake-having and cake-eating. :)
Isn't this problem si
I'm wondering if it would make sense (or be possible) to override -
retain and -release to increment/decrement your own variable in
addition to using the inherited behavior. In the GC environment, the
inherited retain does nothing but in either environment your
enumerator can detect the re
On 11 Apr 2008, at 16:07, Michael Ash wrote:
On Fri, Apr 11, 2008 at 6:04 AM, Alastair Houghton
<[EMAIL PROTECTED]> wrote:
Under GC, these kinds of tricks are no longer possible because
there is no
-retain call any more, so no way to tell if it is safe to re-
initialise and
return the same w
On 11 Apr 2008, at 17:26, Quincey Morris wrote:
On Apr 11, 2008, at 08:07, Michael Ash wrote:
The obvious technique would be to stop trying to make the
optimization
implicit and to make it explicit and managed by the caller instead.
In
other words, you write your API so that it explicitly r
On Apr 11, 2008, at 08:07, Michael Ash wrote:
The obvious technique would be to stop trying to make the optimization
implicit and to make it explicit and managed by the caller instead. In
other words, you write your API so that it explicitly returns the same
object every time you call -nextObje
On Fri, Apr 11, 2008 at 6:04 AM, Alastair Houghton
<[EMAIL PROTECTED]> wrote:
> Under GC, these kinds of tricks are no longer possible because there is no
> -retain call any more, so no way to tell if it is safe to re-initialise and
> return the same wrapper object.
>
> Aside from re-implementing
Hi all,
On a number of occasions I've found myself in a situation where I have
a data structure (often a complex one) that is implemented in C, but
for which I want an ObjC wrapper. As an example, let's consider a
tree of nodes.
Now, obviously it would be good to provide NSEnumerator sub
13 matches
Mail list logo
