[swift-users] Swift4/iOS question

[Travis Griggs via swift-users]

If I need to take this question elsewhere, please point me to the right list.

I decided to take the dive this morning and give XCode9 beta and Swift 4 a try. 
I’m tired of not being able to refactor.

There are two things that the importer is trying to commonly change that I’m 
curious about:

1) Anywhere I’ve linked a UIControl to a method via the addTarget(self, action: 
#selector(foobar), for: .valueChanged), it now feels that foobar needs to be 
annotated as @objc. I really liked that so far in my swift journey, I’ve never 
had to put one of these @objc things in. I think I get what’s going on. My 
class is a swift class, but is a subclass from UIViewController, an objc class. 
While apparently, it could infer that subclass methods should be objc callable, 
they no longer are?

What’s frustrating is that if UIControl just had an action API that used 
closures instead of the older perform: patterns, I’d just rewrite these as 
such. But it still doesn’t. So people still make extensions which have to 
resort to static globals or associated_objects.

2) I have a couple of CALayer subclasses that have a couple different ways of 
setting/accessing the same thing. I use dynamic vars for those. Once upon a 
time, someone told me that I needed to make them dynamic for the animation 
engine to correctly note changes to them. Apparently, those all need to be 
tagged @objc now. Which seems redundant to me. Are not dynamic vars already 
implicitly objc anyway? Is the new need to add @objc just for consistency sake?
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] any wisdom about sharing "common" overloads/extensions in base libraries?

[Travis Griggs via swift-users]

> On Jun 20, 2017, at 2:25 PM, Travis Griggs  wrote:
> 
>> 
>> On Jun 20, 2017, at 7:02 AM, David Baraff via swift-users 
>> > wrote:
>> 
>> I posted this on Apple’s developer forums, and someone suggested trying this 
>> here.
>> Basically, see https://forums.developer.apple.com/thread/80349 
>> 
>> 
>> but in a nutshell: consider that a widely used class/struct (such as 
>> CGPoint) is missing some “obvious” functionality [don’t debate that part, 
>> just go with it for now], such as the ability to scale a point by a scalar 
>> using * as an operator: so in my awesome library “GeometryBase” I write
>> 
>>   public func * (left: CGPoint, right: double) -> CGPoint {
>>   return CGPoint(x: right*left.x, y: right*left.y)
>>   }
>> 
>> Why public?  Well, of course, because I want to use library GeometryBase in 
>> many apps or other libraries, and now this overload exists in only one place.
>> 
>> But other bright people have the same idea, and now I want to use their 
>> libraries.  (some of them in my company, some of them not.)
>> 
>> And now we’re stuck, because everyone is trying to make up for the same 
>> (perceived) lack and everyone wants them public so that they don’t have to 
>> keep sticking them in each library they write.
>> 
>> This is not a made up situation: many people even within one company trying 
>> to share code somewhat informally are going to write the same code to make 
>> using CGPoint/Size/Rect easier, and now we can’t share anything safely.
>> 
>> Anybody got some good ideas what to do about this?
>> 
>> [Same question could apply to adding extensions.]
> 
> I don’t have a good idea how to solve the problem. We dealt with this type of 
> thing many years ago in Smalltalk systems.
> 
> Strategically, when I write application code for end user consumption, I will 
> use my goodly sized library of base library extensions. But when I’m writing 
> a framework to be used by other programmers, I swear off the extensions. If 
> there is an extension that is just so essential, I’ll restrain its scope as 
> much as possible, both with ACLs as well as obvious name prefixes:
> 
>   extension CGPoint {
>   var radius_myFramework:CGFloat {
>   return sqrt((self.x * self.x) + (self.y * self.y))
>   }
> 
> This doesn’t do much for infix signatures though.
> 
> That said, I’m glad to have this problem in Swift. I’m willing to live with 
> the hassle it can create. The gain is worth it. I hate that Python won’t let 
> me extend base types.

Also, reading about Kotlin recently, I found the exposition of extensions 
interesting:

https://kotlinlang.org/docs/reference/extensions.html 


In particular the part about them being resolved statically. I’ve wondered if 
this helps obviate this conflict problem, but I haven’t thought through it 
enough yet.

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] any wisdom about sharing "common" overloads/extensions in base libraries?

[Travis Griggs via swift-users]

> On Jun 20, 2017, at 7:02 AM, David Baraff via swift-users 
>  wrote:
> 
> I posted this on Apple’s developer forums, and someone suggested trying this 
> here.
> Basically, see https://forums.developer.apple.com/thread/80349 
> 
> 
> but in a nutshell: consider that a widely used class/struct (such as CGPoint) 
> is missing some “obvious” functionality [don’t debate that part, just go with 
> it for now], such as the ability to scale a point by a scalar using * as an 
> operator: so in my awesome library “GeometryBase” I write
> 
>   public func * (left: CGPoint, right: double) -> CGPoint {
>   return CGPoint(x: right*left.x, y: right*left.y)
>   }
> 
> Why public?  Well, of course, because I want to use library GeometryBase in 
> many apps or other libraries, and now this overload exists in only one place.
> 
> But other bright people have the same idea, and now I want to use their 
> libraries.  (some of them in my company, some of them not.)
> 
> And now we’re stuck, because everyone is trying to make up for the same 
> (perceived) lack and everyone wants them public so that they don’t have to 
> keep sticking them in each library they write.
> 
> This is not a made up situation: many people even within one company trying 
> to share code somewhat informally are going to write the same code to make 
> using CGPoint/Size/Rect easier, and now we can’t share anything safely.
> 
> Anybody got some good ideas what to do about this?
> 
> [Same question could apply to adding extensions.]

I don’t have a good idea how to solve the problem. We dealt with this type of 
thing many years ago in Smalltalk systems.

Strategically, when I write application code for end user consumption, I will 
use my goodly sized library of base library extensions. But when I’m writing a 
framework to be used by other programmers, I swear off the extensions. If there 
is an extension that is just so essential, I’ll restrain its scope as much as 
possible, both with ACLs as well as obvious name prefixes:

extension CGPoint {
var radius_myFramework:CGFloat {
return sqrt((self.x * self.x) + (self.y * self.y))
}

This doesn’t do much for infix signatures though.

That said, I’m glad to have this problem in Swift. I’m willing to live with the 
hassle it can create. The gain is worth it. I hate that Python won’t let me 
extend base types.

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Restricting associated values

[Travis Griggs via swift-users]

> On Jun 18, 2017, at 10:33 PM, Howard Lovatt via swift-users 
>  wrote:
> 
> To me Angle is a unit with two common representations: radians and degrees. 
> It's not an enum because it doesn't have two values, it has one value that 
> you can view in two ways.
> 
> Therefore I would make an Angle struct, something like:
> 

Lots of different ways I think. I chose not between struct and enum, but used 
both:

struct Angle {
enum Unit:CGFloat {
case radians = 1.0
case degrees = 57.29577951309314 // 360.0 / Tau
case rotations = 0.1591549430918953 // 1.0 / Tau
}

// MARK: - Stored Properties
var raw:CGFloat = 0.0
var unit:Unit = .radians
….
// MARK: - Left for the Student

I do a bit of UI programming with angles and have found rotations (I’ve drunk 
too much of the Tau manifesto koolaid probably) to be the most natural fit for 
a lot of things. Having an angle object allows me to layer over (via 
extensions) the various cocoa/uikit apis that take angles with type safe angle 
objects, and yet given me the ability to express said angles in whatever 
intermediate domain best fits.
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Future(of: self.references)?

[Travis Griggs via swift-users]

> On May 22, 2017, at 5:56 PM, Greg Power  wrote:
> 
> Hi Travis,
> 
> I’m certainly not a core contributor, but I could point you to the rejection 
> email for this proposal, which you might not have seen:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/005478.html
>  
> 
> 
> It states that the core team felt that the proposal was not the right 
> direction for Swift, and lists a few reasons.
> 
> The main reason appears to be that enforcing a mandatory self for instance 
> members would increase the visual clutter of the language, which is counter 
> to Swift's goals of clarity and minimal boilerplate.
> 
> That email links to Paul Cantrell’s response to the proposal, which is also a 
> really good (and elucidating) read: 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002910.html
>  
> .
> 
> No need for flame or heat!
> 

Thank you Greg (and others) for the replies. I don’t think much of the 
*rationale* stated there, especially actually Paul Cantrell’s. BUT, I can 
appreciate that it was a “contentious” issue. And as said, I didn’t come to 
stir the pot. Merely to get clarification.

I did my time in the language wars of the late 90’s and early 00’s. After a 
while, like real wars, I came to realize the pointlessness of a lot of it. 
Perspectives are huge, e.g. brevity of characters and brevity in consistency 
are two different things that can counter each other and be argued equally by 
both sides in the name of brevity. History repeats itself. Swift has lots to 
like.

It would be great if there was a switch in a tool like Xcode that would insert 
magical “self” bubbles for visual consistency wherever they appeared. But then… 
I’m still wondering if we’ll ever see refactoring tools emerge in Xcode for 
Swift (and beginning to lose hope).___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Can I have my cake and share it too with extensions?

[Travis Griggs via swift-users]

In my own project, I add some extensions to Data and other objects to make 
building/parsing Data objects easier. Amongst others, I have extensions like 
this:

func += (data:inout Data, string:String) {
data.append(string.data(using: .utf8)!)
}

func += (data:inout Data, convertible:DataConvertible) {
data.append(convertible.data)
}

I use it widely.

But I’ve also been incorporated a small single file MQTT implementation 
(LightMQTT) that is shared as an ad hoc component with others. I’ve been trying 
to simplify the implementation of LightMQTT to use a similar technique, but the 
way things encode themselves is a little different (e.g. a string puts a 2 byte 
big endian count before itself, etc). Naively, I had added extensions like such:

protocol MQTTDataAppendable {
static func += (data:inout Data, appendee:Self)
} 

extension UInt8:MQTTDataAppendable {
static func += (data:inout Data, appendee:UInt8) {
data.append(appendee)
}
}

extension UInt16:MQTTDataAppendable {
static func += (data:inout Data, appendee:UInt16) {
data += UInt8((appendee & 0xFF00) >> 8) 
data += UInt8(appendee & 0xFF)
}
}

extension String:MQTTDataAppendable {
// 
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718016
static func += (data:inout Data, appendee:String) {
data += UInt16(appendee.utf8.count)
data.append(appendee.data(using: .utf8)!)
}
}

So in the same code space, when I tried then use expressions like:

packet += “MQTT”

The compiler gets cornfuzzled because there’s of course ambiguous resolution of 
+=. I get why this is. The question I guess is can I pull this off (regardless 
of whether its a good idea or not, because I suspect it may not be, but I still 
want to know). I toyed with sprinkling fileprivate in front of those 
extensions, but it didn’t like the way I did it.

I could just make a Packet struct that wraps a Data struct I think, and that 
would keep the two from colliding. Curious what other solutions (good or bad) 
would allow the overloaded operator extensions to be disambiguated?
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Swift 3.1 String(

[Travis Griggs via swift-users]

> On Apr 5, 2017, at 7:37 AM, Jon Shier via swift-users  
> wrote:
> 
>   This was something that sounded like a good change but is extremely 
> annoying in use. Once I get time I’m going to try writing an extension on 
> Optional that generates a logDescription property so I don’t have to use that 
> awful String(describing:) API.

Couldn’t agree more. If you get your extension/fix done before me, share please?

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] [swift-evolution] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Travis Griggs via swift-users]

Not sure if I got the "reply all" right… I’ll throw my 2c in.

I like mailing lists. I like them, because they let me choose the viewer that I 
want to participate with(separation of presentation and data). I lose that with 
a web forum. And there’s something valuable about actually forcing people to 
reduce their questions/answers to simple textual communications. 

I’m not familiar with “Discourse”, but I guess I can learn new things. But I 
think this “bring your own viewer” is a meaningful thing for some people, so if 
it can be a hybrid (doubling as a mailing list), then I’m cool with that.

In general, I’ve found mailing lists to be longer lasting and more vibrant than 
any of the forums I’ve dealt with, especially of late. The only exception I can 
think of would be the StackWhatever sites, and even those I’ve noticed seem to 
be less useful of late. I find it’s harder to get your questions noticed in 
forums.
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Confused by this error message

[Travis Griggs via swift-users]

I’m currently refactoring some code (Swift 3.?, latest XCode), and I ended up 
with the following:

func spansTSON() -> TSON {
var docs = self.spans.map() { $0.tson }
for (span, doc) in zip(self.spans, docs) {
if let datum = span.begin.datum {
if let index = self.spans.index(where: {return 
$0.includesAnchor(datum)}) {
doc["datum"] = (index * 2 + 
(datum.isBegin ? 0 : 1)).tson
}
}
}
return TSON.array(docs)
}

The vague error I get is “Ambiguous reference to spans” on the “if let index = 
self.spans…” line with the “self” highlighted. The container is a class. 
“spans” is computed property. I’m not sure if it’s confused about what self is, 
or spans. Or why either wouldn’t be clear.
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Confused by this error message

[Travis Griggs via swift-users]

> On Jan 30, 2017, at 3:19 PM, Travis Griggs  wrote:
> 
> I’m currently refactoring some code (Swift 3.?, latest XCode), and I ended up 
> with the following:
> 
>   func spansTSON() -> TSON {
>   var docs = self.spans.map() { $0.tson }
>   for (span, doc) in zip(self.spans, docs) {
>   if let datum = span.begin.datum {
>   if let index = self.spans.index(where: {return 
> $0.includesAnchor(datum)}) {
>   doc["datum"] = (index * 2 + 
> (datum.isBegin ? 0 : 1)).tson
>   }
>   }
>   }
>   return TSON.array(docs)
>   }
> 
> The vague error I get is “Ambiguous reference to spans” on the “if let index 
> = self.spans…” line with the “self” highlighted. The container is a class. 
> “spans” is computed property. I’m not sure if it’s confused about what self 
> is, or spans. Or why either wouldn’t be clear.

Nevermind.

I had a few moments before added a setter function that looked like func 
spans(tson:TSON)


___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Confused/Surprised by IndexingIterator.forEach behavior

[Travis Griggs via swift-users]

The behavior of the following playground snippet surprised me:

var source = [10, 20, 30, 40]
var stream = source.makeIterator()
stream.next()  // 10
stream.next()  // 20
stream.forEach { (each) in
print("\(each)")
}  // prints 30, 40 to the console
stream.next()  // 30
stream.next()  // 40
stream.next()  // nil

I can move the forEach statement up and down the stack there, and it *appears* 
that while it respects the the current position of the stream/iterator as a 
start point, it does not actually consume the elements (as next does). That 
seems inconsistent to me I guess. I would have expected the forEach to either 
pass through to the source and just ignore the current position, or to consume 
the items. Whereas the current behavior is kind of a hybrid. 

Guess I’m just looking for some enlightenment as to why it was designed to work 
this way. I figure there’s some valuable insight here that I’m missing.
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Regression in Xcode8-beta6 Swift?

[Travis Griggs via swift-users]

Upgrading to beta6 of Xcode8, I’ve read through various SE’s and made fixes as 
appropriate, but the following behavior I didn’t catch an explanation as to why 
its now an error where it was fine before.

In a ViewController, I have something that looks like:

var addButton = UIButton(type: .custom)
var addPrompt = UILabel()
var timesButton = UIButton(type: .system)
var removeButton = UIButton(type: .system)
var menuButton = UIButton(type: .system)

func commonInit() {
[self.addButton, self.addPrompt, self.timesButton, self.removeButton, 
self.menuButton].forEach { control in
control.sizeToFit()
self.addSubview(control)
}

This code was fine until the latest update. It seemed to a heterogenous array 
of UILabel and UIButtons was a homogeneous array of UIView objects. But now I 
get the errors:

Value of type ‘Any’ has no member ‘sizeToFit'
Cannot covert value of type ‘Any’ to expected argument type of ‘UIView’

This seems like it might be related to SE-0116 (Import Objective-C id as Swift 
Any ) but I’m not sure why the inferencer can no longer find the shared parent 
type, where it could before.

Aside, I can fix it by simply helping it a little, e.g.

[self.addButton, self.addPrompt, self.timesButton, self.removeButton, 
self.menuButton].forEach { (control:UIView) in...

But remain curious why the inferencer can’t handle this for me anymore.



___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Date and Data

[Travis Griggs via swift-users]

> On Aug 3, 2016, at 3:36 PM, Jon Shier  wrote:
> 
> If you think Date and Data look similar at a glance, wouldn’t NSDate and 
> NSData? Or are you comparing this against your old Array type?

Fair question. I did think of that. I did actually port this code from 
Objective C. For whatever reason, it wasn’t as noticeable (to me) there. ObjC 
doesn’t lend itself to as “tight” of code, it’s got extra verbosity everywhere, 
so maybe it was less noticeable in that case. I honestly don’t know.

I realized right after I wrote this, that I could also

typealias Timestamp = Date

And reap similar benefits. The fact that some have coined data as "The World's 
Worst Variable Name” makes me tend to shy away from it already I guess.
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] They had parens upon thars

[Travis Griggs via swift-users]

Chapter 1:

Coming from a Smalltalk background, I was enjoying added all kinds of 
properties to basic number types, for example:

extension Double {
var rounded:Double {
return round(self)
}
}

Chapter 2: 

I upgraded to XCode8Beta4 yesterday and firstly got to change all of 
UIColor.someColor() calls to UIColor.someColor accessors.

Secondly I got to scratch my head for a while regarding the cryptic compiler 
errors I was now getting from my Double.rounded extension. I finally found that 
FloatingPoint has added a rounded() method. Creating a conflict with my rounded 
property (I presume). So removed my extension and changed all of the accesses 
of rounded to be calls to rounded(), as well as change the rounded properties I 
had made for my own Angle and Duration enums for to rounded() methods for 
consistencies sake.

Chapter 3:

At this point, I felt a bit like a Sneetch (Dr Seuss). I was basically 
shuffling empty parens around my code base to make the new version happy.

I realize it can probably never be black and white, but is there at least some 
guidelines as to when a property ought to be a niladic method, and when a 
niladic method ought to be a property?
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users