On Tue, 17 Jun 2014 01:02:32 -0400, Manu via Digitalmars-d
<[email protected]> wrote:
On 17 June 2014 13:18, Walter Bright via Digitalmars-d
<[email protected]> wrote:
On 6/16/2014 5:48 PM, Manu via Digitalmars-d wrote:
Hmmm, I still don't buy it,
I know, but you also have not responded to my explanation of why. Such
as
the "dec" being required to be inside an expensive exception handler.
Granted. I don't really understand the situation well enough to
comment with any authority. What are the conditions that create the
requirement, or could relax it?
The problem is if something throws, it need an implicit catch to
release the ref right?
This is the issue, because the release can do a LOT of shit. It could
release a whole tree of objects, it could start throwing its own
exceptions.
It's like doing a lot of stuff inside a signal handler. Possible, but very
hairy.
A possible solution might be to defer the releasing until the exception is
caught, and have the catch statement call all the releases. Just speaking
from ignorance, I don't know if this solves Walter's concern. The stack
unwinding still would have to figure all this stuff out. But if we just
add these calls to a release pool that is drained at the catch point,
maybe it helps solve the problem.
BTW, as a general response, I don't think swift is as proven yet as
Objective C. As has been pointed out many times, one of the greatest (and
arguably worst) parts of Objective C is that any C code is valid Objective
C code. This means, you can instantly go into unsafe C mode if you need
the performance.
From what I can tell, swift does NOT allow that, there will need to be
some sort of bridge there. I think it will make code that uses pure
objective C calls and methods more pleasant to write (i.e. UI and
framework code). I'm not sure how I feel about it yet, I have yet to use
Swift. But I am hesitant to say that swift will be a step forward
performance-wise. Apple claims it is, we shall see.
-Steve
