On Jun 28, 2013, at 5:26 PM, Kyle Sluder wrote:
> On Fri, Jun 28, 2013, at 05:17 PM, Matt Neuburg wrote:
>> Why is the block permitted to assign to the variable sharedInstance
>> outside the block? Evidently it is because "static" has an effect like
>> "__block", in that it makes the variable ou
On Jun 29, 2013, at 9:20 AM, Matt Neuburg wrote:
> I'm trying to come up with a pithy explanation, suitable for beginners, of
> why a "static" variable doesn't need a "__block" specifier in order for a
> block to assign to it. The word "captured", as you suggest, may be useful
> here, since t
On Sat, Jun 29, 2013, at 09:20 AM, Matt Neuburg wrote:
> I take it that the distinction we're drawing here is between static
> storage (which happens at file level and is therefore permanent)
Nitpick: static _storage_ doesn't have anything to do with the _file_.
The `static` keyword applied to a v
On Sat, Jun 29, 2013, at 09:53 AM, Kyle Sluder wrote:
> Yes. In order to make it possible to capture local variables in a block,
> they are potentially hoisted to a storage that has the same lifetime as
> the block. For readonly accesses, that doesn't matter; the value of the
> expression is captur
On Jun 29, 2013, at 10:00 AM, Kyle Sluder wrote:
> In the first case, the block context captured the _value_ of a. In the
> second, it captured the _pointer to b's movable storage_.
That's a nice example, because it also focuses on the *other* practical aspect
of __block, namely that it causes
That is *extremely* clear - thanks! m.
On Jun 29, 2013, at 9:42 AM, Jens Alfke wrote:
>
> On Jun 29, 2013, at 9:20 AM, Matt Neuburg wrote:
>
>> I'm trying to come up with a pithy explanation, suitable for beginners, of
>> why a "static" variable doesn't need a "__block" specifier in order fo
I will be out of the office Fri. June 28.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update
As you know, these days, we are allowed to declare an instance variable in
curly braces in the @implementation section rather than the @interface section.
Well, then:
* Suppose two classes, MyClass and its subclass MyClass2.
* Suppose MyClass publicly declares an instance variable "thing".
I o
On Jun 29, 2013, at 10:23 AM, Matt Neuburg wrote:
> Am I reading this right? It's permitted to override an inherited instance
> variable, but only if you do so privately? m.
First, you can’t override an instance variable; they aren’t dynamic enough. An
ivar is like a struct field, it compiles
On Jun 29, 2013, at 10:55 AM, Jens Alfke wrote:
> This is just a parsing issue. If an ivar is declared in a class’s public
> interface, it’s in scope in any method of that class or a subclass. So if a
> subclass declares an ivar with the same name, you now have a conflict and the
> parser won
Trying this again, reply all this time...
Jens, I think you’ve got the question backwards: the public ivar is in the base
class, and the private one is in the subclass, and it works, even though they
should both be in scope in the subclass’s implementation. I suppose it could be
basically C-sty
Was there ever a satisfactory answer to this? I'm not sure what the CD
modelling answer is, but this seems to be related to relational modelling
referential integrity or in plainer language - no dangling pointers - in db
language a foreign key must have a primary key in another relation.
For ex
On Jun 29, 2013, at 11:18 AM, Matt Neuburg wrote:
>
> On Jun 29, 2013, at 10:55 AM, Jens Alfke wrote:
>
>> This is just a parsing issue. If an ivar is declared in a class’s public
>> interface, it’s in scope in any method of that class or a subclass. So if a
>> subclass declares an ivar with
13 matches
Mail list logo
