> On Jun 20, 2017, at 2:25 PM, Travis Griggs <travisgri...@gmail.com> wrote: > >> >> On Jun 20, 2017, at 7:02 AM, David Baraff via swift-users >> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote: >> >> I posted this on Apple’s developer forums, and someone suggested trying this >> here. >> Basically, see https://forums.developer.apple.com/thread/80349 >> <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 <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
