Re: Swift: How to determine if a Character represents whitespace?

[Charles Jenkins]

I kept my original question as brief as I could, but let me tell you what 
problem I’m trying to solve, and maybe someone will have good advice I haven’t 
yet considered.

I’m trying to code in pure Swift. I have an NSAttributedString which can 
potentially be very large, and I want to save off the 
attributedSubstringFromRange: which represents the string with leading and 
trailing whitespace trimmed. I’m trying to avoid copying the giant string 
merely to determine the proper substring range for copying it again.

Swift has a built-in func stringByTrimmingCharactersInSet(set: NSCharacterSet) 
-> String which won’t help me because using it would copy the string and 
discard the attributes. Even using it for length-testing wouldn’t work, because 
I have no way to know how many characters were trimmed off the head versus the 
tail of the string.

What would be nice is a way to count leading and trailing characters in place 
while the thing is still an NSAttributedString--without using 
NSAttributedString.string to convert to a Swift string in the first place. If 
there were no conversion to the unicode-compliant and amazingly 
difficult-to-do-anything-with-it Swift string, I’d be more confident that the 
shrunken range I calculate would be apples to apples.

-- 

Charles

On April 2, 2015 at 01:25:40, Quincey Morris 
(quinceymor...@rivergatesoftware.com) wrote:

On Apr 1, 2015, at 21:17 , Charles Jenkins  wrote:

for ch in String(char).utf16 {  
if !set.characterIsMember(ch) { found = false }  
}  

Except that this code can’t possibly be right, in general. 

1. A ‘unichar’ is a UTF-16 code value, but it’s not a Unicode code point. Some 
UTF-16 code values have no meaning as “characters” by themselves. I think you 
could mitigate this problem by using ‘longCharacterIsMember’, which takes a 
UTF-32 code value instead (and enumerating the string as UTF-32 instead of 
UTF-16).

2. A Swift ‘Character’ isn’t a Unicode code point, but rather a grapheme. That 
is, it might be a sequence of code points (and I mean code points, not code 
values). It might be such a sequence either because there’s no way of 
representing the grapheme by a single code point, or because it’s a composed 
character made up of a base code points and some combining characters.

In this case, you can’t validly test the individual code points for membership 
of the character set.

I’m not sure, but I suspect the underlying obstacle is that NSCharacterSet is 
at best a set of code points, and you cannot test a grapheme for membership of 
a set of code points.

In your particular application, if it’s true that all** Unicode whitespace 
characters are represented as a single code point (via a single UTF-32 code 
value), or a single UTF-16 code value, then you can get away with one of the 
above solutions. Otherwise you’re going to need a more complex solution, that 
doesn’t involve NSCharacterSet at all.



** Or at least the ones you happen to care about, but ignoring the others may 
be a perilous proceeding.

___

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 your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Swift: How to determine if a Character represents whitespace?

[Uli Kusterer]

On 02 Apr 2015, at 13:54, Charles Jenkins mailto:cejw...@gmail.com>> wrote:
> What would be nice is a way to count leading and trailing characters in place 
> while the thing is still an NSAttributedString--without using 
> NSAttributedString.string to convert to a Swift string in the first place. If 
> there were no conversion to the unicode-compliant and amazingly 
> difficult-to-do-anything-with-it Swift string, I’d be more confident that the 
> shrunken range I calculate would be apples to apples.


Does Swift have an equivalent to rangeOfCharacterFromSet:options: or would that 
require converting it to NSString?

Because you could just generate the inverse NSCharacterSet to the whitespace 
character set, and then look for the first (NSAnchoredSearch) and last 
(NSAnchoredSearch | NSBackwardsSearch) non-whitespace character, and then 
extract only the range between those two offsets.

Wildly guessing,
-- Uli Kusterer
http://stacksmith .org
___

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 your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Swift: How to determine if a Character represents whitespace?

[Ken Thomases]

On Apr 2, 2015, at 6:54 AM, Charles Jenkins  wrote:

> What would be nice is a way to count leading and trailing characters in place 
> while the thing is still an NSAttributedString--without using 
> NSAttributedString.string to convert to a Swift string in the first place.

NSAttributedString.string does not involve a conversion.  The underlying string 
is part of NSAttributedString's data model.  The documentation for the method 
explicitly says, "For performance reasons, this property returns the current 
backing store of the attributed string object."

I don't know if there's a conversion to create a Swift string from that, but 
you don't have to.  I believe you can work with NSString in Swift.

Regards,
Ken


___

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 your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Swift: How to determine if a Character represents whitespace?

[Charles Jenkins]

The documentation certainly says that, Ken, but stick this code in a playground 
and see that you can’t examine the characters via index no matter whether you 
assume it to be String or NSString:

let whitespaceSet = NSCharacterSet.whitespaceAndNewlineCharacterSet()
let attrStr = NSAttributedString( string:"    Fourscore and seven years ago   
\n\n\n\t\t\t   " )
let str = attrStr.string

var head = 0
let tooFar = attrStr.length
while head < tooFar {
  if whitespaceSet.characterIsMember( str.characterAtIndex( head ) ) {
    // Skip -- I did it this way so the error message received from the above 
line will be clear
  } else {
    break;
  }
  ++head
}

var headIx = str.startIndex
let tooFarIx = str.endIndex
while headIx < tooFarIx {
  if whitespaceSet.characterIsMember( str[ headIx ] ) {
    // Skip
  } else {
    break;
  }
  headIx = headIx.successor()
}

characterAtIndex() doesn’t work because it’s not available in Swift. If you 
replace str.characterAtIndex( head ) with with str[ head ], you get the same 
error as in the version below it that incorrectly assumes it’s a Swift string: 
“Could not find overload of 'subscript' that accepts the supplied arguments.”

Now, I did just type this out on a computer running Xcode 6.2. At home I’m 
using 6.3 beta, so it’s possible I’ll get home and find one of these versions 
works as expected, even though I’m sure I tried both ways last night when I 
first hit the roadblock…

I’m now guessing that maybe converting from NSString to String and examining 
characters via one of the UTF views might possibly not involve a copy. But then 
how do I decide which view I should be using...

-- 

Charles

On April 2, 2015 at 08:44:52, Ken Thomases (k...@codeweavers.com) wrote:

On Apr 2, 2015, at 6:54 AM, Charles Jenkins  wrote:  

> What would be nice is a way to count leading and trailing characters in place 
> while the thing is still an NSAttributedString--without using 
> NSAttributedString.string to convert to a Swift string in the first place.  

NSAttributedString.string does not involve a conversion. The underlying string 
is part of NSAttributedString's data model. The documentation for the method 
explicitly says, "For performance reasons, this property returns the current 
backing store of the attributed string object."  

I don't know if there's a conversion to create a Swift string from that, but 
you don't have to. I believe you can work with NSString in Swift.  

Regards,  
Ken  

___

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 your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Swift: How to determine if a Character represents whitespace?

[Charles Jenkins]

Oops. My documentation viewer was set up wrong. characterAtIndex() is indeed 
supposed to be available in Swift. Don’t know what I’ve done wrong that I can’t 
use it in a playground.

-- 

Charles

On April 2, 2015 at 10:18:00, Charles Jenkins (cejw...@gmail.com) wrote:

The documentation certainly says that, Ken, but stick this code in a playground 
and see that you can’t examine the characters via index no matter whether you 
assume it to be String or NSString:

let whitespaceSet = NSCharacterSet.whitespaceAndNewlineCharacterSet()
let attrStr = NSAttributedString( string:"    Fourscore and seven years ago   
\n\n\n\t\t\t   " )
let str = attrStr.string

var head = 0
let tooFar = attrStr.length
while head < tooFar {
  if whitespaceSet.characterIsMember( str.characterAtIndex( head ) ) {
    // Skip -- I did it this way so the error message received from the above 
line will be clear
  } else {
    break;
  }
  ++head
}

var headIx = str.startIndex
let tooFarIx = str.endIndex
while headIx < tooFarIx {
  if whitespaceSet.characterIsMember( str[ headIx ] ) {
    // Skip
  } else {
    break;
  }
  headIx = headIx.successor()
}

characterAtIndex() doesn’t work because it’s not available in Swift. If you 
replace str.characterAtIndex( head ) with with str[ head ], you get the same 
error as in the version below it that incorrectly assumes it’s a Swift string: 
“Could not find overload of 'subscript' that accepts the supplied arguments.”

Now, I did just type this out on a computer running Xcode 6.2. At home I’m 
using 6.3 beta, so it’s possible I’ll get home and find one of these versions 
works as expected, even though I’m sure I tried both ways last night when I 
first hit the roadblock…

I’m now guessing that maybe converting from NSString to String and examining 
characters via one of the UTF views might possibly not involve a copy. But then 
how do I decide which view I should be using...

-- 

Charles

On April 2, 2015 at 08:44:52, Ken Thomases (k...@codeweavers.com) wrote:

On Apr 2, 2015, at 6:54 AM, Charles Jenkins  wrote:

> What would be nice is a way to count leading and trailing characters in place 
> while the thing is still an NSAttributedString--without using 
> NSAttributedString.string to convert to a Swift string in the first place.

NSAttributedString.string does not involve a conversion. The underlying string 
is part of NSAttributedString's data model. The documentation for the method 
explicitly says, "For performance reasons, this property returns the current 
backing store of the attributed string object."

I don't know if there's a conversion to create a Swift string from that, but 
you don't have to. I believe you can work with NSString in Swift.

Regards,
Ken

___

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 your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Swift: How to determine if a Character represents whitespace?

[Jens Alfke]

> On Apr 2, 2015, at 4:54 AM, Charles Jenkins  wrote:
> 
> What would be nice is a way to count leading and trailing characters in place 
> while the thing is still an NSAttributedString--without using 
> NSAttributedString.string to convert to a Swift string in the first place. If 
> there were no conversion to the unicode-compliant and amazingly 
> difficult-to-do-anything-with-it Swift string, I’d be more confident that the 
> shrunken range I calculate would be apples to apples.

Use NSString.rangeOfCharactersFromSet() on the attributed string’s underlying 
NSString.

Don’t use any native Swift String character accessors, because the character 
positions aren’t going to agree with NSString since they use different 
interpretations of Unicode.

—Jens
___

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 your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSWindow Subclass close/dealloc question

[Dave]

Hi,

I’m getting a crash in dealloc in an NSWindow Subclass.

I have a class that creates and closes Windows based on Notifications received 
from elsewhere. One of the Notifications is “CloseWindow”. 

I added this to my subclass:

-(void) close
{
LogIfDave(@"Overlay close");

[super close];  //Crashes with this line in, ok without.
}


-(void) dealloc
{
LogIfDave(@"Overlay dealloc");

self.prop1 = nil;
self.prop2 = nil;
self.prop3 = nil;

[super dealloc];
}

The Call Sequence when I get the notification is:

[self.overlay close];
self.overlay = nil; //this causes release to be 
called, e.g. the retainCount is == 1,

overlay is defined as:

@property (nonatomic,retain) LTWOverlay*overlay;


If I run this, then I get a crash when the autorelease pool is drained. 
However, if I take out the line:

[super close];

in my close method, all works fine.

Is this expected?

All the Best
Dave






___

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 your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSWindow Subclass close/dealloc question

[Ken Thomases]

On Apr 2, 2015, at 10:56 AM, Dave  wrote:

> I’m getting a crash in dealloc in an NSWindow Subclass.

> If I run this, then I get a crash when the autorelease pool is drained. 
> However, if I take out the line:
> 
> [super close];
> 
> in my close method, all works fine.
> 
> Is this expected?

If you have a window which is not being controlled by a window controller and 
whose releasedWhenClosed property is true (default for NSWindow), then it will 
be released when it is closed (unsurprisingly).  Therefore, you should not 
release it again yourself or you will over-release it and cause a crash (or 
worse).

The easiest thing to do is to always turn off releasedWhenClosed so that window 
objects obey normal memory management conventions.

Regards,
Ken


___

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 your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSWindow Subclass close/dealloc question

[Dave]

> On 2 Apr 2015, at 17:09, Ken Thomases  wrote:
> 
> On Apr 2, 2015, at 10:56 AM, Dave  wrote:
> 
>> I’m getting a crash in dealloc in an NSWindow Subclass.
> 
>> If I run this, then I get a crash when the autorelease pool is drained. 
>> However, if I take out the line:
>> 
>> [super close];
>> 
>> in my close method, all works fine.
>> 
>> Is this expected?
> 
> If you have a window which is not being controlled by a window controller and 
> whose releasedWhenClosed property is true (default for NSWindow), then it 
> will be released when it is closed (unsurprisingly).  Therefore, you should 
> not release it again yourself or you will over-release it and cause a crash 
> (or worse).
> 
> The easiest thing to do is to always turn off releasedWhenClosed so that 
> window objects obey normal memory management conventions.
> 
> Regards,
> Ken

Hi thanks for this, Yes, releasedWhenClosed because there it used a lot of 
memory. I guess I could just test of releasedWhenClosed == YES and NOT call 
[super close]; in my subclasses close method?

All the Best
Dave


___

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 your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Another NSWindow Question

[Dave]

Hi,

Is there a method similar in use to UIView’s layoutSubviews method? e.g a 
layoutWindow method.

When the window is resized, I want to replace the Content View with a new one, 
is there a better way of doing this.

This is a special case Overlay window that doesn’t have a Window Controller.

All the Best
Dave


___

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 your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Swift: How to determine if a Character represents whitespace?

[Quincey Morris]

On Apr 2, 2015, at 04:54 , Charles Jenkins  wrote:

> Swift has a built-in func stringByTrimmingCharactersInSet(set: 
> NSCharacterSet) -> String  

There is something wacky going on here — or not. (I know you don’t want to use 
this particular method, but I’m just using it as an example.)

First of all, String and NSString are different classes, for real. Quoting a 
god-like personage, in a recent thread:

> On Mar 23, 2015, at 13:52 , Greg Parker  wrote:
> 
>> Most of NSString's methods are re-implemented in a Swift extension on class 
>> String. You get this extension when you `import Cocoa`.

And indeed, if you try this in a playground:

> let strA = "Hello, string"
> let strB = "Hello, NSString" as NSString
> let a = strA.characterAtIndex (6) // line 3
> let b = strB.characterAtIndex (6) // line 4


you get an error at line 3, as you would expect/hope (since Strings aren’t 
“made of” unichars), but no error in line 4 (since NSStrings are).

So it’s not odd that String.stringByTrimmingCharactersInSet would return a 
String. What’s very odd is that *in Swift* 
NSString.stringByTrimmingCharactersInSet returns a String — not a NSString — as 
does NSAttributedString.string, or apparently any Cocoa API that would return a 
NSString in Obj-C.

This means it’s not possible *in Swift* to apply NSString methods to a NSString 
and stay entirely within the NSString world without casting/converting. 
*That’s* wacky, given that String and NSString are different classes with 
different (though very similar) APIs.

The only way to un-wack this, that I can think of right now, would be for 
expressions like ‘someNSString.stringByTrimmingCharactersInSet (…) as NSString’ 
to involve only a cheap or free conversion from String to NSString. However 
there is no API contract to this effect AFAIK.

Therefore:

1. We need a god-like personage to step in and un-wack this for real.

2. Subject to the outcome of #1, you can approach this entirely in the NSString 
world, in which case I like Uli’s suggestion, applied to 
'yourAttributedString.string as NSString’. You’d have to verify by performance 
testing that massive conversions aren’t being made.



___

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 your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSWindow Subclass close/dealloc question

[Ken Thomases]

On Apr 2, 2015, at 11:53 AM, Dave  wrote:

> On 2 Apr 2015, at 17:09, Ken Thomases  wrote:
>> 
>> On Apr 2, 2015, at 10:56 AM, Dave  wrote:
>> 
>>> I’m getting a crash in dealloc in an NSWindow Subclass.
>> 
>>> If I run this, then I get a crash when the autorelease pool is drained. 
>>> However, if I take out the line:
>>> 
>>> [super close];
>>> 
>>> in my close method, all works fine.
>>> 
>>> Is this expected?
>> 
>> If you have a window which is not being controlled by a window controller 
>> and whose releasedWhenClosed property is true (default for NSWindow), then 
>> it will be released when it is closed (unsurprisingly).  Therefore, you 
>> should not release it again yourself or you will over-release it and cause a 
>> crash (or worse).
>> 
>> The easiest thing to do is to always turn off releasedWhenClosed so that 
>> window objects obey normal memory management conventions.
>> 
>> Regards,
>> Ken
> 
> Hi thanks for this, Yes, releasedWhenClosed because there it used a lot of 
> memory. I guess I could just test of releasedWhenClosed == YES and NOT call 
> [super close]; in my subclasses close method?

No, then the window will be uncloseable.  What needs to be different depending 
on that property is whether you call -release, not whether you pass the -close 
call up to super.  If you're using ARC, you don't get to control whether you 
call release.  Therefore, you need to set releasedWhenClosed to NO.

If you're experiencing leaks when releasedWhenClosed is false, then that's a 
separate bug in your code, which you need to fix.

Regards,
Ken


___

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 your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSWindow Subclass close/dealloc question

[Dave]

> 
> No, then the window will be uncloseable.  What needs to be different 
> depending on that property is whether you call -release, not whether you pass 
> the -close call up to super.  If you're using ARC, you don't get to control 
> whether you call release.  Therefore, you need to set releasedWhenClosed to 
> NO.
> 
> If you're experiencing leaks when releasedWhenClosed is false, then that's a 
> separate bug in your code, which you need to fix.

No, I’m not using ARC.

releasedWhenClosed is YES.

I alloc/init the NSWindow subclass and store it in a retained property.

When I get the Close notification, I send a Close to the window, then  I set 
the property to nil to release it.

If I don’t call [super close] this all is well and it calls dealloc ok when I 
set he property to nil.

I’m not experiencing any leaks, this code was ported (imported in bits) from 
the pre ARC days (Mac OS X 10.4 I think) and I’m trying to make it work on Mac 
OS X 10.10. 

Are you saying that dealloc calls close?

Since it’s being released straight after the close is sent, does this make the 
releasedWhenClosed setting a bit irrelevant anyway?

I don’t have a problem with setting releasedWhenClosed to NO, it’s just there 
was a comment on the code saying that it made a LOT of difference having to set 
to YES and I’m just trying to figure out it’s supposed to work with 
releasedWhenClosed == YES.

All the Best
Dave



___

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 your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Swift: How to determine if a Character represents whitespace?

[Charles Jenkins]

Amen, brother.

Given my attributed string “attrStr,” I can indeed call 
attrStr.string.rangeOfCharacterFromSet(). But in typical Swift string fashion, 
the return type is as unfriendly as possible: Range? — as if the 
NSString were a Swift string.

So after doing two anchored searches, one at the beginning and one at the end 
of the string, if I get two different ranges, I’m stuck with two values that 
aren’t subtractable to determine the length of the NSRange I need in a call to 
attributedSubstringFromRange(). I think the safest thing for me to do for 
attributed string compatibility is give up on Swift purity and put my 
range-trimming function in an Objective-C file.

— 

Charles

On April 2, 2015 at 2:15:07 PM, Quincey Morris 
(quinceymor...@rivergatesoftware.com) wrote:

On Apr 2, 2015, at 04:54 , Charles Jenkins  wrote:

Swift has a built-in func stringByTrimmingCharactersInSet(set: NSCharacterSet) 
-> String  

There is something wacky going on here — or not. (I know you don’t want to use 
this particular method, but I’m just using it as an example.)

First of all, String and NSString are different classes, for real. Quoting a 
god-like personage, in a recent thread:

On Mar 23, 2015, at 13:52 , Greg Parker  wrote:

Most of NSString's methods are re-implemented in a Swift extension on class 
String. You get this extension when you `import Cocoa`.

And indeed, if you try this in a playground:

let strA = "Hello, string"
let strB = "Hello, NSString" as NSString
let a = strA.characterAtIndex (6) // line 3
let b = strB.characterAtIndex (6) // line 4

you get an error at line 3, as you would expect/hope (since Strings aren’t 
“made of” unichars), but no error in line 4 (since NSStrings are).

So it’s not odd that String.stringByTrimmingCharactersInSet would return a 
String. What’s very odd is that *in Swift* 
NSString.stringByTrimmingCharactersInSet returns a String — not a NSString — as 
does NSAttributedString.string, or apparently any Cocoa API that would return a 
NSString in Obj-C.

This means it’s not possible *in Swift* to apply NSString methods to a NSString 
and stay entirely within the NSString world without casting/converting. 
*That’s* wacky, given that String and NSString are different classes with 
different (though very similar) APIs.

The only way to un-wack this, that I can think of right now, would be for 
expressions like ‘someNSString.stringByTrimmingCharactersInSet (…) as NSString’ 
to involve only a cheap or free conversion from String to NSString. However 
there is no API contract to this effect AFAIK.

Therefore:

1. We need a god-like personage to step in and un-wack this for real.

2. Subject to the outcome of #1, you can approach this entirely in the NSString 
world, in which case I like Uli’s suggestion, applied to 
'yourAttributedString.string as NSString’. You’d have to verify by performance 
testing that massive conversions aren’t being made.

___

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 your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Swift: How to determine if a Character represents whitespace?

[Quincey Morris]

On Apr 2, 2015, at 19:28 , Charles Jenkins  wrote:
> 
> So after doing two anchored searches, one at the beginning and one at the end 
> of the string, if I get two different ranges, I’m stuck with two values that 
> aren’t subtractable to determine the length of the NSRange I need in a call 
> to attributedSubstringFromRange(). 

Not at all. All of this API is *NSString* API, even if the instance happens to 
be String instead of NSString, so the ranges are NSString-compatible ranges 
(i.e. UTF16 code value ranges), so you can just do the subtraction and use the 
result in attributedSubstringFromRange.

> I think the safest thing for me to do for attributed string compatibility is 
> give up on Swift purity and put my range-trimming function in an Objective-C 
> file.


Again, it’s all NSString API, so the results are what the Obj-C API would 
return. Otherwise, interoperability wouldn’t work.

If, additionally, you cast any String-returning result ‘as’ NSString, then you 
literally are doing Obj-C, though it happens to be created by the Swift 
compiler. That is to say, it’s going to make Obj-C-style method calls with an 
Obj-C-NSString-style object as receiver, so the source language is irrelevant. 
(!)

That, or I’ve run wildly off the rails.



___

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 your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Swift: How to determine if a Character represents whitespace?

[Quincey Morris]

On Apr 2, 2015, at 19:28 , Charles Jenkins  wrote:
> 
> I can indeed call attrStr.string.rangeOfCharacterFromSet(). But in typical 
> Swift string fashion, the return type is as unfriendly as possible: 
> Range? — as if the NSString were a Swift string.

I finally read the whole of what you said here, and I had to run to a 
playground to check:

> import Cocoa
> 
> var strA = "Hello?, String”
> var strB = "Hello?, String" as NSString
> var strC = "Hello\u{1f650}, String”
> var strD = "Hello\u{1f650}, NSString" as NSString
> var rangeA = 
> strA.rangeOfCharacterFromSet(NSCharacterSet.whitespaceCharacterSet()) // 
> {Some “7..<8”}
> var rangeB = 
> strB.rangeOfCharacterFromSet(NSCharacterSet.whitespaceCharacterSet()) // (7,1)
> var rangeC = 
> strC.rangeOfCharacterFromSet(NSCharacterSet.whitespaceCharacterSet()) // 
> {Some “8..<9”}
> var rangeD = 
> strD.rangeOfCharacterFromSet(NSCharacterSet.whitespaceCharacterSet()) // (8,1)

So, yes, these are NSString indexes all the way, even if the result is packaged 
as a Range.



___

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 your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Do NSStackView's actually work in a NSTableView?

[Sebastien Boisvert]

I only ask because I’m using a stackview that while it behaves as I configured 
it in a plain view in a window, it behaves completely different when put in a 
tableview. For example, views which I’ve set to detach will never, ever detach, 
regardless of the settings I’ve set.

Anyone have experience with using stackviews in tableviews?
___

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 your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com