I have the following code but i'm facing some issues, maybe related to 'open' keyword.
class CustomPieChartView: PieChartView
{
internal override func initialize()
{
super.initialize()
renderer = PieChartRenderer(chart: self, animator: _animator, viewPortHandler: _viewPortHandler)
_xAxis = nil
self.highlighter = PieHighlighter(chart: self)
}
}
initialize is marked internal inside PieChartView
According to the Swift documentation you cannot access internal members of frameworks (they must be marked open).
Internal access enables entities to be used within any source file
from their defining module, but not in any source file outside of that
module. You typically use internal access when defining an app’s or a
framework’s internal structure.
...
Open class members can be overridden by subclasses within the module
where they’re defined, and within any module that imports the module
where they’re defined.
The maintainer(s) of Charts may not want that method to be overridden but since it's open source perhaps you/someone can attempt to have that changed if there is a good reason or use case.
Related
I have a class that extends another. The parent class is not intended to be used directly by the API rather it implements basic methods that are helpers for child classes.
When I use the child class in a program I can see all method from said class but also the one from the parent class that are not intended to be called directly, they exist to be called by the methods of the child class.
I tried to make parents method private. This would work I believe as long as parent and child are declared in the same library. But I have an issue with the "library" notion. I understand part/part of are somewhat depreciated, and I want the parent class to be in a specific file. I can't figure a way to do it with import/export.
Is there a way to either hide a public method from the parent class from all child classes usage or to make a private method from the parent class callable from all child classes ?
Best regards ;
Exemple:
myLib.dart
export mainClass.dart;
mainClass.dar
import baseClass.dart;
class MainClass extends BaseClass {
publicFunc() => ... //Can't call _hiddenFunc, can call wantToHideFunc()
}
In a second file (for code reusability purposes)
class MainClass extends BaseClass {
_hiddenFunc() => ...
wantToHideFunc() => ...
}
Using myLib public API
import myLib.dart
main() {
class = Class();
class.publicFunc(); //Intended
class.wantToHideFunc() //Wants to avoid...
}
Dart does not have protected access like Java or C#.
You can't hide a public member, you can't access a private member from a different library, and there is no third option.
It sounds like you want members of the superclass which can be invoked only from subclasses, not from outside of the object. That's what's called protected in, e.g., Java, and Dart does not have anything similar to that.
The only level of privacy in Dart is library-private, which is chosen by starting the name with a _.
The reason that Dart has this design is that it was originally a very dynamic language. You can preform "dynamic invocations" on a value with static type dynamic, say dynVal.foo(42) and it will call the method of that name.
To make a name unreachable, it needed to be safe from dynamic invocation as well. Because of that, Dart privacy does not care where the code doing the invocation is, it only cares whether you know the name - and library private names are considered different names depending on which library they're from.
Using part is not discouraged for situations where it actually serves a purpose. If you can put the part into a library of its own, that's better because it allows it to have its own privacy and imports, but if you need the classes to share privacy, using part files to split up a large file is perfectly reasonable. It's a tool, there is nothing wrong with using it when it's the right tool for the job. A library is often a better tool for modularity, but not always.
Now, there is a hack you can use:
// Declare the base and provide extensions for "protected" members:
abstract class Base {
int get _someHiddenStuff => 42;
int get somePublicStuff => 37;
}
extension ProtectedBase on Base {
int get someHiddenStuff => _someHiddenStuff;
}
Then import that in another library and do:
import "base.dart";
export "base.dart" hide ProtectedBase;
class SubClass extends Base {
int doSomething => someHiddenStuff + somePublicStuff;
}
Then anyone importing "subclass.dart" will also get a version of Base, but they won't get the ProtectedBase extensions. Hiding the extensions from your package's public API will allow yourself to use it, but prevent your package's users from seeing the helper extensions.
(This is likely highly over-engineered, but it's an option. It's the evolution of the hack of having static/top-level helper functions that you don't export.)
In Swift, I have historically used extensions to extend closed types and provide handy, logic-less functionality, like animations, math extensions etc. However, since extensions are hard dependencies sprinkled all over your code-base, I always think three times before implementing something as an extension.
Lately, though, I have seen that Apple suggests using extensions to an even greater extent, e.g. implementing protocols as separate extensions.
That is, if you have a class A that implement protocol B, you end up with this design:
class A {
// Initializers, stored properties etc.
}
extension A: B {
// Protocol implementation
}
As you enter that rabbit-hole, I started seeing more extension-based code, like:
fileprivate extension A {
// Private, calculated properties
}
fileprivate extension A {
// Private functions
}
One part of me likes the building-blocks you get when you implement protocols in separate extensions. It makes the separate parts of the class really distinct. However, as soon as you inherit this class, you will have to change this design, since extension functions cannot be overridden.
I think the second approach is...interesting. Once great thing with it is that you do not have to annotate each private property and function as private, since you can specify that for the extension.
However, this design also splits up stored and non-stored properties, public and private functions, making the "logic" of the class harder to follow (write smaller classes, I know). That, together with the subclassing issues, makes me halt a bit on the porch of extension wonderland.
Would love to hear how the Swift community of the world looks at extensions. What do you think? Is there a silverbullet?
This is only my opinion, of course, so take what I'll write easy.
I'm currently using the extension-approach in my projects for few reasons:
The code is much more clean: my classes are never over 150 lines and the separation through extensions makes my code more readable and separated by responsibilities
This is usually what a class looks like:
final class A {
// Here the public and private stored properties
}
extension A {
// Here the public methods and public non-stored properties
}
fileprivate extension A {
// here my private methods
}
The extensions can be more than one, of course, it depends on what your class does. This is simply useful to organize your code and read it from the Xcode top bar
It reminds me that Swift is a protocol-oriented-programming language, not an OOP language. There is nothing you can't do with protocol and protocol extensions. And I prefer to use protocols for adding a security layer to my classes / struct. For example I usually write my models in this way:
protocol User {
var uid: String { get }
var name: String { get }
}
final class UserModel: User {
var uid: String
var name: String
init(uid: String, name: String) {
self.uid = uid
self.name = name
}
}
In this way you can still edit your uid and name values inside the UserModel class, but you can't outside since you'll only handle the User protocol type.
I use a similar approach, which can be described in one sentence:
Sort a type's responsibilities into extensions
These are examples for aspects I'm putting into individual extensions:
A type's main interface, as seen from a client.
Protocol conformances (i.e. a delegate protocol, often private).
Serialization (for example everything NSCoding related).
Parts of a types that live on a background thread, like network callbacks.
Sometimes, when the complexity of a single aspect rises, I even split a type's implementation over more than one file.
Here are some details that describe how I sort implementation related code:
The focus is on functional membership.
Keep public and private implementations close, but separated.
Don't split between var and func.
Keep all aspects of a functionality's implementation together: nested types, initializers, protocol conformances, etc.
Advantage
The main reason to separate aspects of a type is to make it easier to read and understand.
When reading foreign (or my own old) code, understanding the big picture is often the most difficult part of diving in. Giving a developer an idea of a context of some method helps a lot.
There's another benefit: Access control makes it easier not to call something inadvertently. A method that is only supposed to be called from a background thread can be declared private in the "background" extension. Now it simply can't be called from elsewhere.
Current Restrictions
Swift 3 imposes certain restrictions on this style. There are a couple of things that can only live in the main type's implementation:
stored properties
overriding func/var
overidable func/var
required (designated) initializers
These restrictions (at least the first three) come from the necessity to know the object's data layout (and witness table for pure Swift) in advance. Extensions can potentially be loaded late during runtime (via frameworks, plugins, dlopen, ...) and changing the type's layout after instances have been created would brake their ABI.
A modest proposal for the Swift team :)
All code from one module is guaranteed to be available at the same time. The restrictions that prevent fully separating functional aspects could be circumvented if the Swift compiler would allow to "compose" types within a single module. With composing types I mean that the compiler would collect all declarations that define a type's layout from all files within a module. Like with other aspects of the language it would find intra file dependencies automatically.
This would allow to really write "aspect oriented" extensions. Not having to declare stored properties or overrides in the main declaration would enable better access control and separation of concerns.
I hate it. It adds extra complexity and muddies the use of extensions, making it unclear on what to expect that people are using the extensions for.
If you're using an extension for protocol conformance, OK, I can see that, but why not just comment your code? How is this better? I don't see that.
I'm building an iOS app where i want to make a protocol (Which by my understanding is the equivalent of java interfaces) for my model, to use for Unit Testing purposes.
In Java you typically want to encapsulate your values in a model and make them accessible through getters and setters only.
How can i ensure this encapsulation in Swift with protocols, where i can't use the private keyword for properties.
My model is setup something like this:
class model {
private var property: Int = 5
func getProperty() -> Int {
return property
}
func setProperty(newValue: Int) {
self.property = newValue
}
}
And i want my protocol to look something like this:
protocol modelProtocol {
private var property: Int { get set }
}
My problem is that i can't declare my properties private, is this just a thing in Swifts access control (I've read they have private, internal and public) that you don't use private properties that much or is there an equivalent to Java's way of handling interfaces and private variables?
(Note: I'm using Xcode 7 and swift 2.0 if that matters)
I don't think that you can have private properties and public Getters and Setters with Swift code, as the getters and setters cannot have a higher access control than the property. For unit testing purposes you can access any internal entity using the #testable attribute as shown in the documentation below.
Access Levels for Unit Test Targets
When you write an app with a unit test target, the code in your app needs to be made available to that module in order to be tested. By default, only entities marked as public are accessible to other modules. However, a unit test target can access any internal entity, if you mark the import declaration for a product module with the #testable attribute and compile that product module with testing enabled.
I do not think you would be able to declare private properties within a protocol, you may need to use a base class instead with internal properties and extend that class. I am still fairly new to protocols myself, but I believe they are mainly used to ensure code conforms to that protocol as in... it provides that functionality or those methods.
References Used:
Swift Access Control
Swift Properties
Swift unit testing access
Using swift I created a framework Common that contains functions and protocols I use repeatedly to cut down on code reuse.
Common.framework
public protocol CommonProtocol {}
I than created a framework that I want to share with others which includes some classes that extends CommonProtocol and passes CommonProtocol in response to some function calls.
Sharable.framework
public class Sharable : CommonProtocol {
func getCommon() -> CommonProtocol
}
Unfortunately when I attempt to use Sharable.framework in a Project I get there error:
Swift Compiler ErrorUse of undeclared type 'CommonProtocol'
Does anyone know how to make the protocol visible to Modules that use the Sharable.framework?
I am copying the frame Common.framework in the Copy Files step to Destination Frameworks (there was no noticeable change when I made it Shared Frameworks)
If possible I would prefer to only make certain protocols from Common.framework visible through Sharable.framework and I don't want to force my users to import multiple frameworks if I can avoid it.
class XYActivity: UIActivity,YouTubeHelperDelegate
{
var youTubeHelper:YouTubeHelper
var uploadURL: String!
override init() {
self.youTubeHelper = YouTubeHelper()
}
override func activityType() -> String? {
return nil
}
//
}
I want to make uploadURL public, That is, to be assigned in other class.
When I add public infront of var uploadURL:String! it suggest me to make it as internal. I wanna make it public. Please help
In order to make it public, the class must be declared as public.
By default the modifier is internal, which makes classes, methods and properties not explicitly declared as private available anywhere in the current module.
If your project consists of an app only, then you probably don't need public - internal has the same effect. If you are developing a framework instead, and need that property accessible from code in other modules, then you need to declare the entire class and the exposed methods/properties as public.
Suggested reading: Access Control
Excerpt describing default access levels:
All entities in your code (with a few specific exceptions, as described later in this chapter) have a default access level of internal if you do not specify an explicit access level yourself. As a result, in many cases you do not need to specify an explicit access level in your code.
and access levels for single-target apps:
When you write a simple single-target app, the code in your app is typically self-contained within the app and does not need to be made available outside of the app’s module. The default access level of internal already matches this requirement. Therefore, you do not need to specify a custom access level. You may, however, want to mark some parts of your code as private in order to hide their implementation details from other code within the app’s module.
You can make it public if the class that contains it is also public, so change that according to it.
JuST ADD a keyword "public" at start this will make it public in the app.
Very neatly explained on docs.swift.org