Date   

Re: UIDocumentInteractionController with non-standard file types

Steve Christensen
 

On Jul 11, 2017, at 2:53 PM, Steve Mills <sjmills@...> wrote:

My iOS app has 2 custom UTIs declared in the Imported UTIs section, and 3 Document Types (those 2, plus pdf). When I try to share a file (doesn't matter if the URL's UTI is one of the custom types or pdf), it presentOpenInMenuFromBarButtonItem:animated: fails. If I use presentOptionsMenuFromBarButtonItem:buttonItem:animated:, it works.

This is all in the simulator, so there might not be any apps that Open In will work with. The files are in my app's Documents dir. I have the delegate set to my view controller, and I implemented ALL UIDocumentInteractionControllerDelegate the methods so I could log which ones get called. None get called when I use the OpenIn version. Here are the messages in the simulator's log when I use the OptionsMenu version. Could it be an entitlements problem?

Jul 11 16:49:52 MN5669AM007052 Box of Fun[69053]: UIDocumentInteractionControllerDelegate implements legacy action methods. Please remove them.
Jul 11 16:49:52 MN5669AM007052 Box of Fun[69053]: can perform print:
Jul 11 16:49:52 MN5669AM007052 Box of Fun[69053]: can perform copy:
Jul 11 16:49:52 MN5669AM007052 Box of Fun[69053]: can perform saveToCameraRoll:
Jul 11 16:49:53 MN5669AM007052 Box of Fun[69053]: will present options
Jul 11 16:49:55 MN5669AM007052 pkd[33271]: SecTaskLoadEntitlements failed error=22 cs_flags=200, task->pid_self=-1
Jul 11 16:49:55 MN5669AM007052 pkd[33271]: SecTaskCopyDebugDescription: Box of Fun[69053]
Jul 11 16:49:55 MN5669AM007052 Box of Fun[69053]: SecTaskLoadEntitlements failed error=22 cs_flags=200, task->pid_self=69053
Jul 11 16:49:55 MN5669AM007052 Box of Fun[69053]: SecTaskCopyDebugDescription: Box of Fun[69053]
Jul 11 16:49:59 MN5669AM007052 Box of Fun[69053]: presented open in
Jul 11 16:50:06 MN5669AM007052 assertiond[33257]: assertion failed: 14F2411 13C75: assertiond + 13207 [792516D1-991E-36EE-8454-16F8220758D6]: 0x1

Sent from iCloud's ridiculous UI, so, sorry about the formatting


UIDocumentInteractionController with non-standard file types

Steve Mills
 

My iOS app has 2 custom UTIs declared in the Imported UTIs section, and 3 Document Types (those 2, plus pdf). When I try to share a file (doesn't matter if the URL's UTI is one of the custom types or pdf), it presentOpenInMenuFromBarButtonItem:animated: fails. If I use presentOptionsMenuFromBarButtonItem:buttonItem:animated:, it works.

This is all in the simulator, so there might not be any apps that Open In will work with. The files are in my app's Documents dir. I have the delegate set to my view controller, and I implemented ALL UIDocumentInteractionControllerDelegate the methods so I could log which ones get called. None get called when I use the OpenIn version. Here are the messages in the simulator's log when I use the OptionsMenu version. Could it be an entitlements problem?

Jul 11 16:49:52 MN5669AM007052 Box of Fun[69053]: UIDocumentInteractionControllerDelegate implements legacy action methods. Please remove them.
Jul 11 16:49:52 MN5669AM007052 Box of Fun[69053]: can perform print:
Jul 11 16:49:52 MN5669AM007052 Box of Fun[69053]: can perform copy:
Jul 11 16:49:52 MN5669AM007052 Box of Fun[69053]: can perform saveToCameraRoll:
Jul 11 16:49:53 MN5669AM007052 Box of Fun[69053]: will present options
Jul 11 16:49:55 MN5669AM007052 pkd[33271]: SecTaskLoadEntitlements failed error=22 cs_flags=200, task->pid_self=-1
Jul 11 16:49:55 MN5669AM007052 pkd[33271]: SecTaskCopyDebugDescription: Box of Fun[69053]
Jul 11 16:49:55 MN5669AM007052 Box of Fun[69053]: SecTaskLoadEntitlements failed error=22 cs_flags=200, task->pid_self=69053
Jul 11 16:49:55 MN5669AM007052 Box of Fun[69053]: SecTaskCopyDebugDescription: Box of Fun[69053]
Jul 11 16:49:59 MN5669AM007052 Box of Fun[69053]: presented open in
Jul 11 16:50:06 MN5669AM007052 assertiond[33257]: assertion failed: 14F2411 13C75: assertiond + 13207 [792516D1-991E-36EE-8454-16F8220758D6]: 0x1

Sent from iCloud's ridiculous UI, so, sorry about the formatting


Printing NSTextView puts text in middle of page - Solved

tridiak
 

Sorry for noise. Found the solution 5mins after I sent the email.

Mark


Re: NSInteger and NSUInteger

dhoerl
 

Xcode list 2013:

Date: Sun, 17 Nov 2013 15:38:22 -0500
From: Andy Lee <aglee@...>
To: "Gerriet M. Denkmann" <gerriet@...>
Cc: Xcode Users <xcode-users@...>
Subject: Re: printing NSUInteger in iOS
Message-ID: <E2CA2BAA-E03C-4850-8F42-7D3611A21C75@...>
Content-Type: text/plain; charset=us-ascii

I've been grudgingly casting, but there is this, which I haven't yet memorized:

<https://twitter.com/gparker/status/377910611453046784>
%zd, %tu, %tx (signed, unsigned, hex) currently format NSInteger and NSUInteger with no warnings.
--Andy


Re: NSInteger and NSUInteger

dhoerl
 

Original post of this solution came from no other than Greg Parker!


Printing NSTextView puts text in middle of page

tridiak
 

Printing a NSTextView centres the text (if it is less than one page in size) vertically in the page, as opposed to the top.
What do you need to do to fix this?

let tv = NSTextView()
tv.textStorage?.append(ats)


var npo = NSPrintOperation.init(view: tv);
tv.frame.size.width = (sampleViewScroll.documentView?.frame.size.width)!;
tv.frame.size.height = 20000; // or some large number
npo.run();

The attributed text (ats) is valid (displayed in a visible NSTextView).

Do I need to calculate the size of the text and set the margins?
Or is there a justification setting I am missing?

TIA
Mark


Re: NSInteger and NSUInteger

Steve Christensen
 

On Jul 10, 2017, at 6:13 AM, Steve Mills <sjmills@...> wrote:

On Jul 10, 2017, at 04:54:24, Gerriet M. Denkmann <g@...> wrote:

Formats for NS(U)Integer:
%t… (%td, %to, %tu %tx, %tX) for unsigned results NSUInteger
%z… (%zd, %zo, %zu %zx, %zX) for signed results NSInteger

Where did you find this info? I've seen mention of them, but never an official type doc that lists them.

General information on format specifiers is here:


I use %td for NSInteger and %tu for NSUInteger. The 't' is a length modifier specifying that a following d, o, u, x, or X conversion specifier applies to a ptrdiff_t or the corresponding unsigned integer type argument. That allows you to use the same format specifier for both 32- and 64-bit platforms, get the correct results, and avoid compiler warnings.


Re: NSInteger and NSUInteger

Gerriet M. Denkmann
 

On 10 Jul 2017, at 20:36, Dave <dave@looktowindward.com> wrote:

Thanks a lot for this - where did you find it?
Probably this was posted on Apple’s CocoaDev mailing list by someone who surely knows about these things.

Gerriet.


Re: NSInteger and NSUInteger

Dave
 

Hi,

Thanks a lot for this - where did you find it?

Cheers
Dave

On 10 Jul 2017, at 11:54, Gerriet M. Denkmann <g@mdenkmann.de> wrote:


On 10 Jul 2017, at 16:37, Dave <dave@looktowindward.com> wrote:

I’m trying to use NSInteger and/or NSUInteger in a InitWithFormat statement, I’m using %ld as the specifier but this is producing warnings? Has this changed recently, because code that used to compile without warnings now cause warnings. What is the correct specifier to use for these types?
Formats for NS(U)Integer:
%t… (%td, %to, %tu %tx, %tX) for unsigned results NSUInteger
%z… (%zd, %zo, %zu %zx, %zX) for signed results NSInteger

Gerriet.




Re: NSInteger and NSUInteger

Steve Mills
 

On Jul 10, 2017, at 04:54:24, Gerriet M. Denkmann <g@mdenkmann.de> wrote:


Formats for NS(U)Integer:
%t… (%td, %to, %tu %tx, %tX) for unsigned results NSUInteger
%z… (%zd, %zo, %zu %zx, %zX) for signed results NSInteger
Where did you find this info? I've seen mention of them, but never an official type doc that lists them.

--
Steve Mills
Drummer, Mac geek


Re: NSInteger and NSUInteger

Gerriet M. Denkmann
 

On 10 Jul 2017, at 16:37, Dave <dave@looktowindward.com> wrote:

I’m trying to use NSInteger and/or NSUInteger in a InitWithFormat statement, I’m using %ld as the specifier but this is producing warnings? Has this changed recently, because code that used to compile without warnings now cause warnings. What is the correct specifier to use for these types?
Formats for NS(U)Integer:
%t… (%td, %to, %tu %tx, %tX) for unsigned results NSUInteger
%z… (%zd, %zo, %zu %zx, %zX) for signed results NSInteger

Gerriet.


NSInteger and NSUInteger

Dave
 

Hi,

I’m trying to use NSInteger and/or NSUInteger in a InitWithFormat statement, I’m using %ld as the specifier but this is producing warnings? Has this changed recently, because code that used to compile without warnings now cause warnings. What is the correct specifier to use for these types?

Thanks a lot
All the Best
Dave


Re: BundleDisplayName

Quincey Morris
 

On Jul 9, 2017, at 21:15 , Gerriet M. Denkmann <g@...> wrote:

But I don’t like the asymmetry of it:
Change the Finder name for development region: change PRODUCT_NAME in Build Settings

My guess is that it asymmetric for historical and/or compatibility reasons. There’s also something about the Finder storing a “.Localized…” named file inside the bundle, but I don’t know if that’s still a current thing.

But at least you have a way forward that’s set-and-forget?


Re: BundleDisplayName

Gerriet M. Denkmann
 

On 10 Jul 2017, at 01:13, Quincey Morris <quinceymorris@rivergatesoftware.com> wrote:

On Jul 9, 2017, at 07:45 , Gerriet M. Denkmann <g@mdenkmann.de> wrote:

It never reads Base.lproj, even if the system language = Localization native development region = CFBundleDevelopmentRegion

The problem is that Xcode (obviously unaware of this Finder peculiarity) does NOT allow English as an additional localisation (because the development region already is English; so English speaking computers should just use Base.lproj).

What can be done?
I’m not sure I understand completely, but I think you’re missing one point.

As with the base localization, which (as you say) means that Xcode treats it as the “localization” for the development language, and you omit the actual localization for that language (English in your example), the Finder AFAIK uses the “unlocalized” bundle file name as the “base” file name. (Because it’s a bundle, it’s actually a directory name, but the principle is the same.)

If you the developer are on an English system, you can change the “base” file name any time you want, after the app bundle is created, by renaming it in the Finder. I do this all the time for my apps, and the final “base” name is nowhere in my Xcode project settings. Again AFAIK, this has *no* downstream consequences for localized non-English systems — as you’ve seen, the original name is irrelevant when the Finder actually applies localization to the name.

If you want to create the app with the desired English name during archiving, rather than renaming it later, then you must change build settings. AFAIK the one that controls the bundle’s file name is “Product Name”. The default value of this setting is “$(TARGET_NAME)”. If you don’t want the target name, you can put anything you want in there, minus the extension.

So, I assume that if you put the desired English name of your app in the Product Name setting, you’ll get the results you want in all localizations.
Here the result of my investigations so far:

1. The file-system-name (shown by ls command) = PRODUCT_NAME.
The PRODUCT_NAME is initially set to $(TARGET_NAME).
Changing the Target Name to: “New name” changes the Build settings to: PRODUCT_NAME = “New name”.

2. The app-menu and the About Panel show “Bundle name".

3. The Finder shows “Bundle display name" but only if:
3a. Info.plist contains Bundle display name = $(PRODUCT_NAME)
3b. <current language>.lproj exists, contains InfoPlist.strings and this has CFBundleDisplayName
The Finder does NOT fall back to Base.lproj for current language = development region (as everybody else does).

I fixed my problem by creating a copy of Bundle.lproj/InfoPlist.strings, putting it into an en.lproj folder and adding this in Xcode to the resources of my app.

Sure I could also (as you mentioned) change the PRODUCT_NAME (which has the additional advantage of file-system-name = Finder-name).
But I don’t like the asymmetry of it:
Change the Finder name for development region: change PRODUCT_NAME in Build Settings
Change the Finder name for any other language: change CFBundleDisplayName in xx.lproj/InfoPlist.strings

On the other hand, if the Finder name is the same for all languages, then using the PRODUCT_NAME is clearly better.

Thanks for your help!

One more thing:
Main.strings contains:
/* Class = "NSMenuItem"; title = "AppName"; ObjectID = "1Xt-HY-uBw"; */
"1Xt-HY-uBw.title" = "AppName";

/* Class = "NSMenuItem"; title = "Quit AppName"; ObjectID = "4sb-4s-VLi"; */
“4sb-4s-VLi.title” = “Quit AppName";

I tried to change this to:
"1Xt-HY-uBw.title" = "$(PRODUCT_NAME)";
“4sb-4s-VLi.title” = "Quit $(PRODUCT_NAME)";

But of course the last line does not work.
Could this work?
There are quite a few place where the AppName is hardcoded: About, Quit, Help (maybe more).


Kind regards,

Gerriet.


Re: How to write better Swift

Quincey Morris
 

On Jul 9, 2017, at 14:53 , Fritz Anderson <anderson.fritz@...> wrote:

## Backing store vs property

There's no eliminating the need to reason about it: You cannot _prevent_ the setting of some backing store without executing code. "Backing" describes a passive receptacle, if the word has any meaning at all. Controlling what goes into the receptacle isn't passive; it is the action of whatever owns it.

The problem is that Swift doesn’t have any backing stores separate from properties. As you say (if effect), backing stores are implementation details. In Swift, if a property implementation wants to control what goes into its backing store, it needs a 2nd property. That’s the complaint here, and it’s purely bureaucratic: the 2nd declaration gets more prominence than it deserves; your eye can’t skip it so easily when reading the source of the enclosing type. There’s no real *functional* difference. 

(Also, since I originally posted, I realized that it also gives the 2nd property more *scope* that it should have. Hiding the backing store belonging to a single property from the rest of the implementation seems like a really good idea. How many of us, in Obj-C code, have got ourselves into trouble by using instance variables and property accessors inconsistently in a class implementation?)

You cite the complications in setting state if setting it has side effects. "side effect" → "not passive." You're not writing to a variable, you're executing a setter. You have to put that in the API contract just as you would for things that start with `func`. If it's important that some action _not_ have a certain side effect, that's a different execution path. Swift can't automagically predict problems that arise from sharing a backing store across the implementation of an API.

The side effects I was thinking of were KVO notifications. I’ve been playing with some use-cases in the last couple of weeks, and it’s really, really hard to get this right sometimes without explicit control of a backing store.

Indeed there’s a larger discussion (that I’ve been having in my head) about the possible need for *two* setters, one from the “UI side” and one from the “model” side. The UI setter eventually calls the model setter, but only the model setter generates KVO notifications. 

Why a setter from the UI? The setter is involved on the UI side when the UI element is mutable and uses bindings. OTOH UI methods that don’t use bindings use action methods instead, and (again in the discussion in my head) I’ve been considering whether some action methods are somehow part of properties, as in “get”, “set” and “act” behaviors. That sort of integrates the “act” behavior with the 2nd setter, unifying bindings and actions. Of course, I haven’t worked it out in any detail, so the whole thing might be infeasible or just plain muddled.

## In Swift

TL;DR: Properties should be reserved for things that smell like access to values with no side effects. In practice there's a lot of gray.

## Swift properties are not variables 

Except that Swift has stored properties *and* computed properties, and computed properties have no implicit backing store. By definition, a computed setter can be *nothing but* side effects. As above, if there’s any backing store required, though, that drives you to a 2nd property, which is ugly and a little dangerous for the reasons stated.

Again, we’re talking implementation here, not client API design. The difference between stored and computed properties is opaque to clients of the type, and I agree with you that the semantics *for the client* should be simple, kind of passive, and indistinguishable in the two cases.

FWIW, this all came up for me in the context of wrapping UserDefaults in a customized Swift class that makes user defaults values available as apparently pure Swift properties. This gets hard because UserDefaults doesn’t have properties, it has key/values, which means the ultimate backing store is one of your “broader” cases, and the flow of KVO notifications is not under the wrapper’s direct control, *plus* there are updates arriving from internal sources (including other processes such as ‘defaults write …’ in Terminal!) as well as UI such as a preferences window. So far, I haven’t found a good solution that doesn’t involve the wrapper type having a 2nd private property (as a private backing store) for each property it makes public.


Re: How to write better Swift

Fritz Anderson
 

On Jul 8, 2017, at 9:05 PM, Quincey Morris <quinceymorris@...> wrote:
That doesn’t solve Gerriet’s problem. You can’t *prevent* setting the backing store without writing an actual setter. Similarly, if you want to constrain a value (e.g. keep an Int value >= 1), you can do it in didSet, but only at the cost of two writes to the backing store (which may have side effects).

In that case I think we've gotten deeper than whether a set handler solves Gerriet's problem. I'm beginning to think there is no other good way to express exactly what he wants to do because Swift must provide for a broader case.

If you want to persist something, something has to persist it. In the hardest cases the something is probably not a variable. 

If you want to do something about it — the set of "something"s may be infinite — something has to do it.

Entangling the two (or 1 + n) somethings may often be the best choice, so I wish there were a gentler word than "smell."

---

## Backing store vs property

Your distinction between backing store and property is on-point:

• "Backing store" stores state. That's all it does. It's in the name. How it does that is opaque to client code. It might be implemented through SQL or REST; it might be a good old bit-pattern instance variable. How it's done is not API. Ideally, the only requirement is that it behave-as-if.

• Properties fall elsewhere in the Venn diagram. They may wrap a backing store, they may share in a dependency graph, they may have side effects… You can imagine a property having _only_ side effects, a useful thought because it's clearly an abuse of the syntax. (This horse died during the ObjC `@property` wars.)

This is not a problem unique to Swift, except insofar as how the language requires you to reason about it. There's no eliminating the need to reason about it: You cannot _prevent_ the setting of some backing store without executing code. "Backing" describes a passive receptacle, if the word has any meaning at all. Controlling what goes into the receptacle isn't passive; it is the action of whatever owns it.

You cite the complications in setting state if setting it has side effects. "side effect" → "not passive." You're not writing to a variable, you're executing a setter. You have to put that in the API contract just as you would for things that start with `func`. If it's important that some action _not_ have a certain side effect, that's a different execution path. Swift can't automagically predict problems that arise from sharing a backing store across the implementation of an API.

---

## In Swift

TL;DR: Properties should be reserved for things that smell like access to values with no side effects. In practice there's a lot of gray.

At the extreme I'd say: Property notation should express (+/-) pure functions with no parameters on get, one on set. They change or reflect state; it's safe to repeat invocations; they look like accesses to field variables in C-family `struct`s. Anything with a side effect whether relating to a property or not should be a `func`. That's the extreme. That's where I'd start.

That's not convenient. It's error-prone. I'd like to ask a random-number generator `rng.byte` for the next byte in the sequence. My sanity depends on `will`|`didSet` handlers — but they have problems of their own: Does the contract freeze the dependencies, or risk surprises? (It usually does both.) Cycles? Order dependencies? Side effect invariants that can't immediately be assured, like configuring views that might not exist yet?

That's not a rap on Swift. The problems are irreducible. A designer can only mitigate them. Language designers have no perfect choices.

---

## Swift properties are not variables 

My view of Swift's balance is that properties wrap default getters, setters, and setting handlers that you can replace,* but the language encourages you to forget.** `var nPeople: Int` looks like a C-style allocation of a bit-representable value within a `struct,` but it's syntactic sugar for the whole accessor package. Swift allows you to think a `var` is just a variable, but "`var`" is a red herring.

One may disagree with where Swift strikes the balance (if it's what I say it is). A language with a different balance (maybe one that attaches some kind of [executable] validator to variable declarations) might be ingenious, but it would not be Swift.

\* (The default getter/setter may optimize to POD access in-line; I argue no principle requires it.)

** (Much of what we mean when we tell each other Swift is an easy language suitable for small children is that it's such a relief after being stuck with C for twenty years. Pretty quickly you get into questions that verge on the rabbinical.)

---

## They keep telling me to append a summary

The need for a backing variable isn't peculiar to Swift or to so-called "variables." You can express it however suits you, but the problem (if you see it as one) is irreducible.

    — F


Re: BundleDisplayName

Quincey Morris
 

On Jul 9, 2017, at 07:45 , Gerriet M. Denkmann <g@...> wrote:

It never reads Base.lproj, even if the system language = Localization native development region = CFBundleDevelopmentRegion

The problem is that Xcode (obviously unaware of this Finder peculiarity) does NOT allow English as an additional localisation (because the development region already is English; so English speaking computers should just use Base.lproj).

What can be done?

I’m not sure I understand completely, but I think you’re missing one point.

As with the base localization, which (as you say) means that Xcode treats it as the “localization” for the development language, and you omit the actual localization for that language (English in your example), the Finder AFAIK uses the “unlocalized” bundle file name as the “base” file name. (Because it’s a bundle, it’s actually a directory name, but the principle is the same.)

If you the developer are on an English system, you can change the “base” file name any time you want, after the app bundle is created, by renaming it in the Finder. I do this all the time for my apps, and the final “base” name is nowhere in my Xcode project settings. Again AFAIK, this has *no* downstream consequences for localized non-English systems — as you’ve seen, the original name is irrelevant when the Finder actually applies localization to the name.

If you want to create the app with the desired English name during archiving, rather than renaming it later, then you must change build settings. AFAIK the one that controls the bundle’s file name is “Product Name”. The default value of this setting is “$(TARGET_NAME)”. If you don’t want the target name, you can put anything you want in there, minus the extension.

So, I assume that if you put the desired English name of your app in the Product Name setting, you’ll get the results you want in all localizations.


Re: BundleDisplayName

Gerriet M. Denkmann
 

On 8 Jul 2017, at 20:06, Gerriet M. Denkmann <g@mdenkmann.de> wrote:

macOS 12.5, Xcode Version 8.3.2 (8E2002)

App with Base Internationalisation; Development Language = English, localised for German.

Target = “TargetName” (probably same as PRODUCT_NAME)

Both InfoPlist.strings (Base) and InfoPlist.strings (German) have:
CFBundleDisplayName = “RealName”;

Activity Monitor shows: “RealName”; as do both:
[NSBundle mainBundle].localizedInfoDictionary[@“CFBundleDisplayName”] and
[NSRunningApplication currentApplication].localizedName.

But Finder shows “TargetName” (if system language = English).

When I log in as a user with system language = German, Finder shows: “RealName” as it should.

I find this very confusing and not quite what I expected.

How can I persuade Finder to always use the value from InfoPlist.strings regardless of system language?
Finder (at least in macOS 12.5) seems to work like this:

When an app.bundle is copied into some folder (and only then), it reads TheApp.app/Contents/Resources/<system language>.lproj/InfoPlist.strings and uses the value of CFBundleDisplayName to display the app’s name.

It never reads Base.lproj, even if the system language = Localization native development region = CFBundleDevelopmentRegion

The problem is that Xcode (obviously unaware of this Finder peculiarity) does NOT allow English as an additional localisation (because the development region already is English; so English speaking computers should just use Base.lproj).

What can be done?

Gerriet.


Re: How to write better Swift

Quincey Morris
 

On Jul 8, 2017, at 17:15 , Jens Alfke <jens@...> wrote:

You can implement a property observer instead.

(Also to others suggesting will/didSet)

That doesn’t solve Gerriet’s problem. You can’t *prevent* setting the backing store without writing an actual setter. Similarly, if you want to constrain a value (e.g. keep an Int value >= 1), you can do it in didSet, but only at the cost of two writes to the backing store (which may have side effects).


Re: How to write better Swift

Fritz Anderson
 

I'm missing something, possibly because the example code is abbreviated. Is this not equivalent?

var status: StatusEnum = .uninitialized {
// Sorry, "magic number" literals
// make my teeth itch
didSet {
guard status != oldValue else { return }
switch status {
// etc.
}
}
}

    — F

On Jul 8, 2017, at 12:12 PM, Quincey Morris <quinceymorris@...> wrote:

On Jul 8, 2017, at 06:08 , Gerriet M. Denkmann <g@...> wrote:

is this “privateStatus” really necessary?

This has been bugging me a lot lately. I don’t know a way of avoiding the need for an extra property, and if there is, I’d be glad to hear about it too.

In a way, it’s harmless, but I find it clutters up a sequence of property declarations with what is basically boilerplate.

I’ve been thinking about possible alternatives:

1. (Roughly) Let references to the property name inside computed getters and setters to refer to the backing store, turning a computed property back into a [sort of] stored property.

2. Put the declaration of the private property inside the real property:

var status: Int
{
var privateStatus: Int
get{ return privateStatus }
set(new)
{
if new == privateStatus {return}

… do something here …

privateStatus = new
}
}

The second one is functionally identical to the original code (so it doesn’t need any new compiler design), except for the scoping of the private property name.

1401 - 1420 of 1454