Re: Multiple Inheritance via protocol extensions in Swift

2016-09-07 Thread Quincey Morris
On Sep 6, 2016, at 23:26 , Gerriet M. Denkmann  wrote:
> 
> Anything to be done here? Or should I just forget about protocol extensions?

There’s nothing really wrong here, it’s just that it doesn’t work like you 
think.

There is no *inheritance* of protocol default implementations, which means 
there is no overriding either. You get whichever protocol extension function 
the compiler thinks is visible at that point in the source code (which is, I’m 
sure, deterministic, but I couldn’t tell you the rules when you have multiple 
uses of the same function names like you do), and there’s no run-time dynamism.

That’s why I said earlier you can’t just translate an inheritance design into a 
protocol composition design. There is no semantic equivalence. Trying to get 
around that by creating a mixed inheritance/protocol design turns out to be 
much harder, not easier, than using one or the other exclusively.

If you’re used to inheritance, it’s actually quite hard to re-tool your brain 
to figure out how to solve the problem with protocols. In general, the solution 
has quite a different structure. Rather than asking how to implement an 
inheritance pattern of shared code (which, if you think about it, you’ll 
realize is an implementation decision, not a design decision, although the 
distinction is virtually erased by your familiarity with coming up with 
inheritance patterns), you need to consider what behavior each subclass has, 
abstracting out shared behavior into a series of protocols that are adopted as 
necessary to give the right *combination* of behaviors for each subclass. It’s 
a “horizontal” composition, not a “vertical” layering.

If you have no time for exploration, then stick with inheritance and proceed in 
the usual way. (Apart from initialization, inheritance in Swift should be no 
less capable than inheritance in Obj-C.) If you’re prepared to take your API 
apart bit by bit, then play around with composition until you figure out how it 
all fits together.

___

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

Multiple Inheritance via protocol extensions in Swift

2016-09-07 Thread Gerriet M. Denkmann

Trying to eliminate code duplication I tried to use protocol extensions.
But I ran into a rather grave problem.
This probably is “working as documented”.
But it surely it is not working like I hoped it would.

Here is a Playground example:

protocol Number
{
func aFunction() -> Int
}

extension Number
{
func aFunction() -> Int
{
print("Error: \(self.dynamicType) must override \(#function)")
return 0
}
}

protocol Number1: Number {}

extension Number1
{
func aFunction() -> Int
{
print("\(self.dynamicType) \(#function) returns 1")
return 1
}
}

// in my real code there are also a Number2 and Number3 protocols

class NewSuper: Number
{
func superFunction() -> Int
{
return aFunction()
}
}
class NewSubA: NewSuper
{
func subAFunction() -> Int
{
return aFunction()
}
}
class NewSubA1: NewSubA, Number1 {}

let newA1 = NewSubA1()

let c0 = newA1.aFunction()  //  ok
let c1 = newA1.superFunction()  //  prints: Error: NewSubA1 must override 
aFunction()
let c2 = newA1.subAFunction()   //  prints: Error: NewSubA1 must override 
aFunction()

Anything to be done here? Or should I just forget about protocol extensions?

Gerriet.


___

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

Multiple Inheritance

2012-05-24 Thread Gerriet M. Denkmann
I have an abstract class M with subclasses MAB, MAX, MXB.

There are several lengthy methods A which are used in MAB and MAX, and others 
methods B which are used in MAB and MXB.

Methods A use a property NSUInteger index.
Class MXB has no such property, is has NSIndexSet *indices instead.

Similar for methods B.

Currently these common methods are present in both classes.
But: this is less than perfect - meaning that each change has to be done twice. 

What to do?
Have a file methodsA.m which is included in both MAB and MAX (and same for 
methodsB.m) ?

Other, better solutions?


Kind regards,

Gerriet.


___

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: Multiple Inheritance

2012-05-24 Thread Graham Cox
Turn it into two separate protocols instead, and adopt whichever protocols are 
needed in the concrete implementations. Or if one protocol is a superset of the 
other, a protocol can extend another.


--Graham

On 24/05/2012, at 7:14 PM, Gerriet M. Denkmann wrote:

 Other, better solutions?


___

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: Multiple Inheritance

2012-05-24 Thread Thomas Davie
Implement abstract classes that implement the methods, then use the runtime to 
copy the methods into the classes that should have them in +initialize.

Bob

On 24 May 2012, at 10:14, Gerriet M. Denkmann wrote:

 I have an abstract class M with subclasses MAB, MAX, MXB.
 
 There are several lengthy methods A which are used in MAB and MAX, and others 
 methods B which are used in MAB and MXB.
 
 Methods A use a property NSUInteger index.
 Class MXB has no such property, is has NSIndexSet *indices instead.
 
 Similar for methods B.
 
 Currently these common methods are present in both classes.
 But: this is less than perfect - meaning that each change has to be done 
 twice. 
 
 What to do?
 Have a file methodsA.m which is included in both MAB and MAX (and same for 
 methodsB.m) ?
 
 Other, better solutions?
 
 
 Kind regards,
 
 Gerriet.
 
 
 ___
 
 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/tom.davie%40gmail.com
 
 This email sent to tom.da...@gmail.com


___

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: Multiple Inheritance

2012-05-24 Thread Ken Thomases
On May 24, 2012, at 4:14 AM, Gerriet M. Denkmann wrote:

 I have an abstract class M with subclasses MAB, MAX, MXB.
 
 There are several lengthy methods A which are used in MAB and MAX, and others 
 methods B which are used in MAB and MXB.
 
 Methods A use a property NSUInteger index.
 Class MXB has no such property, is has NSIndexSet *indices instead.
 
 Similar for methods B.
 
 Currently these common methods are present in both classes.
 But: this is less than perfect - meaning that each change has to be done 
 twice. 
 
 What to do?
 Have a file methodsA.m which is included in both MAB and MAX (and same for 
 methodsB.m) ?
 
 Other, better solutions?

Perhaps this is a case calling for composition.  Maybe a MAB and a MAX should 
own an A object, while a MAB and MXB should own a B object.  The A object would 
implement the A methods and the index property.  The B object would implement 
the B methods and whatever properties.  If the A and B methods are part of the 
public interface of the subclasses, then they could implement thin wrappers 
that simply forward through to the internal objects.  You could use protocols 
to enforce the requirement that the subclass implement the required interface 
faithfully, if you want.

Or, you can leverage the preprocessor as you suggest.

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: Multiple Inheritance

2012-05-24 Thread Jens Alfke
Implement both A and B in the base class M, but don't declare them in its 
@interface. Then MAB and MAX can both declare method A and have implementations 
that just call super. Likewise for B.

Or, factor out A into a helper class, and similarly for B. Then have MAB and 
MAX instantiate an A helper object and delegate method A to it.

Or, similarly to #2, implement A and B as functions that take the 'receiver' 
object as the first parameter. Then you can easily implement method -A as a 
call to A(self).

—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

Re: Multiple Inheritance

2012-05-24 Thread Gerriet M. Denkmann

On 24 May 2012, at 17:37, Graham Cox wrote:

 Turn it into two separate protocols instead, and adopt whichever protocols 
 are needed in the concrete implementations. Or if one protocol is a superset 
 of the other, a protocol can extend another.

I thought that a protocol only declares methods and properties.

How do I avoid duplicating method implementations using a protocol?

Kind regards,

Gerriet.


___

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: Multiple Inheritance

2012-05-24 Thread Jens Alfke

On May 24, 2012, at 4:15 AM, Gerriet M. Denkmann wrote:

 How do I avoid duplicating method implementations using a protocol?

You don't, other than by using techniques like the ones I described. Protocols 
are just for the convenience (and type-safety) of the _users_ of a class; they 
don't really simplify the implementation.

—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