“SwiftData inheritance relationship”

@IBAction methods usually have a sender argument:@IBAction func myAction(sender: AnyObject){...} //or @IBAction func myAction(sender: UIButton) {...}The sender argument defaults to a type of AnyObject, but it's possible to set the sender's type to UIButton when you create the action. Even if you don't, you can either downcast it from AnyObject to UIButton in the action, or edit your source code to change AnyObject to UIButton. The later works if you know the action will only be called by UIButton instances.Once you have the sender as a UIButton, you can set the sender's enabled state to false:sender.enabled = falseWith this approach, you're sure to set the enabled state on the button that initiated the action.Alternatively, if you also make an IBOutlet for the button, you can refer to the button by the IBOutlet (a property) as opposed to using the sender argument, which lets you change the state from other places in your code, such as after the processing has completed.@IBOutlet weak var myButton: UIButton! /

Doesn't seem to really work very well. I added another parameter which depends on the first. Crashes the compiler (6.4/7.0)protocol MyCollection {typealias T} struct Struct<MC: MyCollection where MC.T == Int, C:CollectionType where C.Element == MC> { init(_ mc: MC) {self.mc = mc} let mc: MC } struct MyCollection_Int: MyCollection {typealias T = Int; typealias C = Array<Int> } let struct_int = Struct(MyCollection_Int())And, of course, there is no covariant typing, so it's not actually possible to say C.Element : MC and build a dependency between those generic type parameters (it'll crash the compiler again, in a different way). You can use the : relationship between two definitely-specified types, but not between generic ones.So even if you do this, your generic type MC may still be broader than it needs to be. There will be type relationships you cannot express and so you'll need to downcast later on.

I don't think there's a straightforward solution to this problem. The issue is that:Mac App Store requires that every piece of code within your app be code signed and sandboxed, including your helper tool.The App Sandbox is, as the name suggests, an app sandbox. So there's no affordance for sandboxing a tool independently of its parent app. Specifically, while you can sandbox a tool, there's no magic that gives the tool access to the paths that are passed to it via command line arguments.Sandbox inheritance (com.apple.security.inherit), which is the way I generally recommend that folks sandbox their tools, does not work for this because Terminal is not sandboxed so, when you run the tool from the command line, there's nothing to inherit from.You may be able to resolve the problem by converting your tool to some sort of script (a shell script, Python, whatever). That's almost certainly feasible from a technical perspective, I just don't know how it interacts with the Mac App Store rules. If n

Oh, sorry for missing your intension.So, back to the original issue.UICollectionViewLayout is an abstract class, so its Methods-to-Override (described in the Subclassing Notes in the UICollectionViewLayout Class Reference) are just placeholders, have no useful implementation and return meaningless results.UICollectionViewFlowLayout is a concrete subclass of UICollectionViewLayout, so all Methods-to-Override work and return results for implementing flow layout, those might be useful when implementing similar layout.So, calling superclass methods like super.prepareLayout() or super.layoutAttributesForItemAtIndexPath(indexPath) are useless when inheriting from UICollectionViewLayout.These may be some help.CircleLayout class in the sample code CircleLayout.APLStackLayout class in the sample code Collection View Transition.And the Creating Custom Layouts section and the Custom Layouts: A Worked Example section in the Collection View Programming Guide for iOS.

These are class factory functions in Objective-C which (AFAIK) means you can't use them to create instances of subclasses.I may be missing something, but all three convenience initalizers are available for subclasses such as your CustomLayoutAttributes which inherits all designated initializers.In fact, even if I replace the layoutAttributesForItemAtIndexPath(_:) method in the sample code CircleLayout as follows, it works: override func layoutAttributesForItemAtIndexPath(path: NSIndexPath) -> UICollectionViewLayoutAttributes? { let attributes = CustomLayoutAttributes(forCellWithIndexPath: path) attributes.size = CGSizeMake(ITEM_SIZE, ITEM_SIZE) attributes.center = CGPointMake(center.x + radius * cos(2 * CGFloat(path.item) * CGFloat(M_PI) / CGFloat(cellCount)), center.y + radius * sin(2 * CGFloat(path.item) * CGFloat(M_PI) / CGFloat(cellCount))) return attributes }Or, you can do something like this, if you want to make your code compliant with subclassing notes. let attributesClass = self.dynamicTy