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

[Howard Lovatt via swift-users]

Jordon Rose from Apple said:

"It's tracked by SR-3908 
. (The description's a little different but it's the same underlying
issue.)"


  -- Howard.

On 21 June 2017 at 12:07, David Baraff  wrote:

>
> On Jun 20, 2017, at 6:59 PM, Howard Lovatt 
> wrote:
>
> There is a *bug* that the Swift people know about, but you are **meant**
> to be able to do this:
>
>
> Is there a plan to fix this?
> If it worked properly this would be quite wonderful.
>
>
>
> ModuleA
>
> A.swift
>
> public protocol P {
>
> func m() -> String
>
> }
>
> extension Int: P {
>
> public func m() -> String { return "AP.m" }
>
> }
>
> ModuleB
>
> B.swift
>
> public protocol P {
>
> func m() -> String
>
> }
> extension Int: P {
>
> public func m() -> String { return "BP.m" }
>
> }
>
> ModuleC
>
> A.swift
>
> import ModuleA
>
> func am(_ i: Int) -> String { return i.m() }
>
> B.swift
>
> import ModuleB
>
> func bm(_ i: Int) -> String { return i.m() }
>
> main.swift
>
> let i = 0
>
> print(am(i))
> print(bm(i))
>
>
>   -- Howard.
>
> On 21 June 2017 at 00:02, David Baraff via swift-users <
> 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
>>
>> 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.]
>>
>>
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>>
>>
>
>
___
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?

[David Baraff via swift-users]

> On Jun 20, 2017, at 6:59 PM, Howard Lovatt  wrote:
> 
> There is a *bug* that the Swift people know about, but you are **meant** to 
> be able to do this:

Is there a plan to fix this?
If it worked properly this would be quite wonderful.


> 
> ModuleA
> A.swift
> public protocol P {
> func m() -> String
> }
> extension Int: P {
> public func m() -> String { return "AP.m" }
> }
> ModuleB
> B.swift
> public protocol P {
> func m() -> String
> }
> extension Int: P {
> public func m() -> String { return "BP.m" }
> }
> ModuleC
> A.swift
> import ModuleA
> func am(_ i: Int) -> String { return i.m() }
> B.swift
> import ModuleB
> func bm(_ i: Int) -> String { return i.m() }
> main.swift
> let i = 0
> print(am(i))
> print(bm(i))
> 
>   -- Howard.
> 
> On 21 June 2017 at 00:02, 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.]
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-users 
> 
> 
> 

___
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?

[Howard Lovatt via swift-users]

There is a *bug* that the Swift people know about, but you are **meant** to
be able to do this:

ModuleA

A.swift

public protocol P {

func m() -> String

}

extension Int: P {

public func m() -> String { return "AP.m" }

}

ModuleB

B.swift

public protocol P {

func m() -> String

}
extension Int: P {

public func m() -> String { return "BP.m" }

}

ModuleC

A.swift

import ModuleA

func am(_ i: Int) -> String { return i.m() }

B.swift

import ModuleB

func bm(_ i: Int) -> String { return i.m() }

main.swift

let i = 0

print(am(i))
print(bm(i))


  -- Howard.

On 21 June 2017 at 00:02, David Baraff via swift-users <
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
>
> 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.]
>
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
___
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 
>> 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 
>> 
>> 
>> 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] any wisdom about sharing "common" overloads/extensions in base libraries?

[Tino Heth via swift-users]

> 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.
Well, have a look at what C++ did: Nothing ;-) — and therefore, the world is 
littered with incompatible, trivial definitions of vectors, images, notes…

My favourite example are quaternions (just do a search for that term in Apples 
own frameworks…), so there is definitely an issue here.
The solution is quite easy, but that makes things really complicated: Just 
declare a standard (that's easy — so everyone wants to have his own one ;-).

Unless someone with outstanding reputation (sadly, Apple seems not to care for 
this) starts a project like Boost, we'll have to live with incompatibilities.

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

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

[David Baraff via swift-users]

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.]

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