I am trying to write an abstract class that partially implements an interface. I also want to set defaults for the non-implemented values. It seems that F# may not support that, but it is equally possible that I just can't get the syntax correct. Any help would be appreciated. This is where I am at so far:
type IDrawable =
abstract member Position : Vector2
abstract member ShortSymbol : int
abstract member ForeColor : string
abstract member BackColor : string
abstract member Symbol : char
abstract member Description : string
[<AbstractClass>]
type DrawableBase(position, shortSymbol, foreColor, backColor) =
let position : Vector2 = position
let shortSymbol : int = shortSymbol
let foreColor : string = foreColor
let backColor : string = backColor
interface IDrawable with
member this.Position = position
member this.ShortSymbol = shortSymbol
member this.ForeColor = foreColor
member this.BackColor = backColor
default this.Symbol = char this.ShortSymbol
default this.Description = ""
new(oldBase: DrawableBase, newPosition) = DrawableBase(newPosition, oldBase.ShortSymbol, oldBase.ForeColor, oldBase.BackColor)
This is for a learning project so most of it doesn't really matter - I'm probably do a few other things wrong here as well - feel free to critique.
I haven't heard about partial interface implementation, even though I have done some OOP work in F# with type inheritance and interfaces. You could achieve the same result with virtual member at the base class:
type IDrawable =
abstract member Position : Vector2
abstract member ShortSymbol : int
abstract member ForeColor : string
abstract member BackColor : string
abstract member Symbol : char
abstract member Description : string
[<AbstractClass>]
type DrawableBase(position, shortSymbol, foreColor, backColor) =
let position : Vector2 = position
let shortSymbol : int = shortSymbol
let foreColor : string = foreColor
let backColor : string = backColor
abstract member Symbol : char
default this.Symbol = char shortSymbol
abstract member Description : string
default this.Description = ""
interface IDrawable with
member this.Position = position
member this.ShortSymbol = shortSymbol
member this.ForeColor = foreColor
member this.BackColor = backColor
member this.Symbol = this.Symbol
member this.Description = this.Description
Because interfaces in F# are explicit, I prefer to implement all interface members as a call to the corresponding type members. E.g. in the previous example the constructor complains that oldBase doesn't have members other than the two virtual ones that I have added:
new(oldBase: DrawableBase, newPosition) = DrawableBase(newPosition, oldBase.ShortSymbol, oldBase.ForeColor, oldBase.BackColor)
One solution is to change the type of oldBase to IDrawable:
new(oldBase: IDrawable, newPosition) = DrawableBase(newPosition, oldBase.ShortSymbol, oldBase.ForeColor, oldBase.BackColor)
Another solution is to add all methods to the type itself. That is more convenient because it allows to avoid explicit casting in many places and work with classes in C# way (where interfaces are implemented implicitly) without annoying :> in every place where one needs to call interface members:
[<AbstractClass>]
type DrawableBase(position, shortSymbol, foreColor, backColor) =
let position : Vector2 = position
let shortSymbol : int = shortSymbol
let foreColor : string = foreColor
let backColor : string = backColor
member this.Position = position
member this.ShortSymbol = shortSymbol
member this.ForeColor = foreColor
member this.BackColor = backColor
abstract member Symbol : char
default this.Symbol = char shortSymbol
abstract member Description : string
default this.Description = ""
interface IDrawable with
member this.Position = this.Position
member this.ShortSymbol = this.ShortSymbol
member this.ForeColor = this.ForeColor
member this.BackColor = this.BackColor
member this.Symbol = this.Symbol
member this.Description = this.Description
new(oldBase: DrawableBase, newPosition) = DrawableBase(newPosition, oldBase.ShortSymbol, oldBase.ForeColor, oldBase.BackColor)
Note that in some rare cases you would want to implement interface not as a call to a type member, but directly as a call to a field or a private method (i.e. duplicate some code and have it as member this.Position = position inside interface as in the type member). This is because for type hierarchies, virtual methods and interfaces inlining at JIT level doesn't always work as with simple classes, so calling member this.Position = this.Position incurs an additional virtual call overhead. But this only matters when you need to nanooptimize, e.g. increase performance from 100 Mops to 150 Mops of a simple method.
Looking at the page for F# interfaces on MSDN here https://msdn.microsoft.com/en-us/library/dd233207.aspx
default is never valid for an interface implementation in a class.
However, again from the docs
However, you can provide a default implementation by also including a
separate definition of the member as a method together with the
default keyword
Related
I've created my class in Dart this way, but I'm getting the Non-nullable instance field 'text' must be initialized. Try adding an initializer expression, or add a field initializer in this constructor, or mark it 'late'. I would like to know if there's a way to do it in a 'Python' style where this kind of class creation is possible, thank you in advance.
class Lexer {
String _text;
int _pos;
String _current_char;
Lexer(String text) {
this._text = text;
this._pos = -1;
this._current_char = '';
this.advance();
}
void advance() {
this._pos++;
this._current_char = this._pos < this._text.length ? this._text[this._pos] : '';
}
}
class Lexer {
String _text;
int _pos;
String _current_char;
This declares several members with type String. Since they are declared as String and not as String?, these members are non-nullable; they are not allowed to ever be null. (This is part of the new null-safety feature from Dart 2.12.)
Dart initializes objects in two phases. When the constructor's body runs, Dart expects all member variables to already be initialized. Because your members are non-nullable and haven't been initialized to non-null values yet, this is an error. The error message explains what you can do:
Non-nullable instance field 'text' must be initialized. Try adding an initializer expression, or add a field initializer in this constructor, or mark it 'late'.
Use initializer expressions. This means using an initializer list:
Lexer(String text)
: _text = text,
_pos = -1,
_current_char = '' {
advance();
}
Note that if you're initializing members with a construction parameter of the same name, you can use shorthand:
Lexer(this._text)
: _pos = -1,
_current_char = '' {
advance();
}
Adding field initializers. This means initializing members inline in the class declaration.
class Lexer {
String _text = '';
int _pos = -1,
String _current_char = '';
Marking your members as late. This means that you promise that the variables will be initialized before anything attempts to use them.
class Lexer {
late String _text;
late int _pos,
late String _current_char;
Making your members nullable, which allows them to be implicitly null by default:
class Lexer {
String? _text;
int? _pos,
String? _current_char;
However, that will require that all accesses explicitly check that the members aren't null before using them.
You also might want to read: Dart assigning to variable right away or in constructor?
So after dart made new keyword optional,
we can initialize an object with exact same syntax but different internal implementation.
class Color {
int r = 0, g = 0, b = 0;
Color({this.r, this.b, this.g});
//Named constructors
Color.red() //Implementation
Color.cyan() //Implementation
// Static Initializers
static Color red() => //Initialze with parameter
static Color cyan() => //Initialze with parameter
}
We can use them like this regardless of being it a named constructor or static method:
Color red = Color.red();
Color cyan = Color.cyan();
What is the place to use each of them?
In practice there is little difference between a factory constructor and a static method.
For a generic class, it changes where you can (and must) write a type parameter:
class Box<T> {
T value;
Box._(this.value);
factory Box.withValue(this.value) => Box<T>._(value);
static Box<T> fromValue<T>(T value) => Box<T>._(value);
}
...
var box1 = Box<int>.withValue(1);
var box2 = Box.fromValue<int>(2);
So, for generic classes, factory constructors are often what you want. They have the most pleasant syntax.
For non-generic classes, there is very little difference, so it's mainly about signaling intent. And deciding which category the name goes into in the DartDoc.
If the main objective of the function is to create a new object, make it a constructor.
If the main objective is to do some computation and eventually return an object (even if it's a new object), make it a static function.
That's why parse methods are generally static functions.
In short, do what feels right for your API.
Constructors and static functions are different. You usually create a named constructor that returns an instance of an object with some predefined values. For example, you have a class called Person which stores Name and Job. You can create this named constructor Person.doctor(name) which you will return a Person object with Job = 'doctor'
class Person{
final name;
final job;
Person(this.name, this.job);
Person.doctor(this.name, {this.job = "doctor"});
}
Static functions or variable persists on all the instance of a class. Let us say, Person has a static variable called count. You increment the count variable whenever an instance of Person is created. You can call Person.count anywhere later in your code to get the value of count (Number of instances of Person)
class Person{
final name;
final job;
static int count;
Person(this.name, this.job){
count++;
}
Person.doctor(this.name, {this.job = "doctor"});
}
Another very useful feature of static class methods is that you can make them asynchronous, i.e. wait for full initialisation in case this depends on some asynchronous operation:
Future<double> getCurrentPrice(String ticker) async {
double price;
// for example, fetch current price from API
price = 582.18;
return price;
}
class Stock {
String ticker;
double currentPrice=0.0;
Stock._(this.ticker);
static Future<Stock> stockWithCurrentPrice(String ticker) async {
Stock stock = Stock._(ticker);
stock.currentPrice = await getCurrentPrice (ticker);
return stock;
}
}
void main() async {
Stock stock = await Stock.stockWithCurrentPrice('AAPL');
print ('${stock.ticker}: ${stock.currentPrice}');
}
Another benefit of the distinction between named constructor and static function is that in the documentation generated the function will be either filed in the construction section or the methods section, which further makes it's intentions clearer to the reader.
A person looking for a constructor in the constructor section of the documentation will easily discover the named constructors as opposed to having to also dig through the static functions section too.
Class1 has a property List<ClassA> xyz = [];. ClassA has a number of properties and methods. ClassB extends ClassA adding additional properties and methods. Is there a way for me to create Class2 extending Class1 but change the TYPE of xyz to List<ClassB>? If that is confusing hopefully code below will give an example of what I'm trying to accomplish. Basically the same as overriding a method but overriding a property.
class Game {
int points;
String opponent;
int opponentPoints;
}
class FootballGame extends Game {
int touchdowns;
int opponentstouchdowns;
}
class BaseballGame extends Game {
int homeruns;
int opponentsHomeruns;
}
class Team {
String name;
List<Game> games;
double winningPercentage() {
int wins = 0;
for(var game in games){
wins += (game.points > game.opponentPoints) ? 1 : 0;
}
return wins / games.length;
}
}
class FootballTeam extends Team {
// How do I change the TYPE of the games property to <FootballGame>
}
You could use the covariant keyword in this case:
class FootballTeam extends Team {
#override
covariant List<FootballGame> games;
}
However, be aware that doing so is potentially unsafe; the reason why you need the covariant keyword is to suppress the type error that arises because the override can violate the contract of the base class: the base class advertises that games can be assigned a List<Game>, but such an assignment would be invalid for the derived class. By using the covariant keyword, you disable the type-check and take responsibility for ensuring that you do not violate the contract in practice.
Note that if the games member were final (or were only a getter), then the override (which uses a more specific type) would be safe and wouldn't need to use covariant.
Edit
I had forgotten that I had written this answer when writing a more detailed answer for a similar question.
Should I make my own getters and setters in Swift? Im confused by the built in getters ad setters...is this even needed?
//properties for the resident
private var name: String!
var apartmentNumber: String!
var email : String!
var phoneNumber : String!
public func getName()->String{
return self.name
}
public func setName(name : String){
self.name = name
}
}
I've written an article for exactly this. I'll paste it here.
Stop writing getters and setters in Swift
I see this time and time again, and it's about time I write an article in one place to consolidate all my thoughts. If you find yourself writing code that looks like this, listen up:
public class C {
private var _i: Int = 0
public var i: Int {
get {
return self._i
}
set {
self._i = newValue
}
}
}
This pattern* is completely pointless in Swift, and I'll explain why, but firstly we need to take a short detour through Java land. Why Java? Because most of the people I run into who write Swift like this have some sort of Java background, either
because it was taught in their computer sceince courses, or
because they're coming over to iOS development, from Android
What's the point of getters and setters?
Suppose we have the following class in Java:
public class WeatherReport {
public String cityName;
public double temperatureF;
public WeatherReport(String cityName, double temperatureF) {
this.cityName = cityName;
this.temperatureF = temperatureF;
}
}
If you showed this class to any CS prof, they're surely going to bark at you for breaking encapsulation. But what does that really mean? Well, imagine how a class like this would be used. Someone would write some code that looks something like this:
WeatherReport weatherReport = weatherAPI.fetchWeatherReport();
weatherDisplayUI.updateTemperatureF(weatherReport.temperatureF);
Now suppose you wanted to upgrade your class to store data in a more sensible temperature unit (beating the imperial system dead horse, am I funny yet?) like Celcius or Kelvin. What happens when you update your class to look like this:
public class WeatherReport {
public String cityName;
public double temperatureC;
public WeatherReport(String cityName, double temperatureC) {
this.cityName = cityName;
this.temperatureC = temperatureC;
}
}
You've changed the implementation details of your WeatherReport class, but you've also made an API breaking change. Because temperatureF was public, it was part of this class' API. Now that you've removed it, you're going to cause compilation errors in every consumer that depended on the exitense of the temperatureF instance variable.
Even worse, you've changed the semantics of the second double argument of your constructor, which won't cause compilation errors, but behavioural errors at runtime (as people's old Farenheit based values are attemped to be used as if they were celcius values). However, that's not an issue I'll be discussing in this article.
The issue here is that consumers of this class will be strongly coupled to the implementation details of your class. To fix this, you introduce a layer of seperation between your implementation details and your interface. Suppose the Farenheit version of our class was implemented like so:
public class WeatherReport {
private String cityName;
private double temperatureF;
public WeatherReport(String cityName, double temperatureF) {
this.cityName = cityName;
this.temperatureF = temperatureF;
}
public String getCityName() {
return this.cityName;
}
public void setCityName(String cityName) {
this.cityName = cityName;
}
public double getTemperatureF() {
return this.temperatureF;
}
public void setTemperatureF(double temperatureF) {
this.temperatureF = temperatureF;
}
}
The getters and setters are really basic methods that access or update our instance variables. Notice how this time, our instance variables are private, and only our getters and setters are public. A consumer would use this code, as so:
WeatherReport weatherReport = weatherAPI.fetchWeatherReport();
weatherDisplayUI.updateTemperatureF(weatherReport.getTemperatureF());
This time, when we make the upgrade to celcius, we have the freedom to change our instance variables, and tweak our class to keep it backwards compatible:
public class WeatherReport {
private String cityName;
private double temperatureC;
public WeatherReport(String cityName, double getTemperatureC) {
this.cityName = cityName;
this.temperatureC = temperatureC;
}
public String getCityName() {
return this.cityName;
}
public void setCityName(String cityName) {
this.cityName = cityName;
}
// Updated getTemperatureF is no longer a simple getter, but instead a function that derives
// its Farenheit value from the Celcius value that actuallyed stored in an instance variable.
public double getTemperatureF() {
return this.getTemperatureC() * 9.0/5.0 + 32.0;
}
// Updated getTemperatureF is no longer a simple setter, but instead a function
// that updates the celcius value stored in the instance variable by first converting from Farenheit
public void setTemperatureF(double temperatureF) {
this.setTemperatureC((temperatureF - 32.0) * 5.0/9.0);
}
// Mew getter, for the new temperatureC instance variable
public double getTemperatureC() {
return this.temperatureC;
}
// New setter, for the new temperatureC instance variable
public void setTemperatureC(double temperatureC) {
this.temperatureC = temperatureC;
}
}
We've added new getters and setters so that new consumers can deal with temperatures in Celcius. But importantly, we've re-implemented the methods that used to be getters and setters for temperatureF (which no longer exists), to do the appropraite conversions and forward on to the Celcius getters and setters. Because these methods still exist, and behave identically as before, we've successfully made out implementation change (storing F to storing C), without breaking our API. Consumers of this API won't notice a difference.
So why doesn't this translate into Swift?
It does. But simply put, it's already done for you. You see, stored properties in Swift are not instance variables. In fact, Swift does not provide a way for you to create or directly access instance variables.
To understand this, we need to have a fuller understanding of what properties are. There are two types, stored and computed, and neither of them are "instance variables".
Stored properties: Are a combination of a comiler-synthesized instance variable (which you never get to see, hear, touch, taste, or smell), and the getter and setter that you use to interact with them.
Computed proepties: Are just a getter and setter, without any instance variable to act as backing storage. Really, they just behave as functions with type () -> T, and (T) -> Void, but have a pleasant dot notation syntax:
print(weatherReport.temperatureC)
weatherReport.temperatureC = 100
rather than a function calling synax:
print(weatherReport.getTemperatureC())
weatherReport.setTemperatureC(100)
So in fact, when you write:
class C {
var i: Int
}
i is the name of the getter and setter for an instance variable the compiler created for you. Let's call the instance variable $i (which is not an otherwise legal Swift identifier). There is no way to directly access $i. You can only get its value by calling the getter i, or update its value by calling its setter i.
So lets see how the WeatherReport migration problem looks like in Swift. Our initial type would look like this:
public struct WeatherReport {
public let cityName: String
public let temperatureF: Double
}
Consumers would access the temperature with weatherReport.temperatureF. Now, this looks like a direct access of an isntance variable, but remember, that's simply not possible in Swift. Instead, this code calls the compiler-syntehsized getter temperatureF, which is what accesses the instance variable $temperatureF.
Now let's do our upgrade to Celcius. We will first update our stored property:
public struct WeatherReport {
public let cityName: String
public let temperatureC: Double
}
This has broken our API. New consumers can use temperatureC, but old consumers who depended on temperatureF will no longer work. To support them, we simply add in a new computed property, that does the conversions between Celcius and Fahenheit:
public struct WeatherReport {
public let cityName: String
public let temperatureC: Double
public var temperatureF: Double {
get { return temperatureC * 9/5 + 32 }
set { temperatureC = (newValue - 32) * 5/9 }
}
}
Because our WeatherReport type still has a getter called temperatureF, consumers will behave just as before. They can't tell whether a property that they access is a getter for a stored property, or a computed property that derives its value in some other way.
So lets look at the original "bad" code. What's so bad about it?
public class C {
private var _i: Int = 0
public var i: Int {
get {
return self._i
}
set {
self._i = newValue
}
}
}
When you call c.i, the following happens:
You access the getter i.
The getter i accesses self._i, which is yet another getter
The getter _i access the "hidden" instance variable $i
And it's similar for the setter. You have two layers of "getterness". See what that would look like in Java:
public class C {
private int i;
public C(int i) {
this.i = i;
}
public int getI1() {
return this.i;
}
public void setI1(int i) {
this.i = i;
}
public int getI2() {
return this.getI1();
}
public void setI2(int i) {
this.setI1(i);
}
}
It's silly!
But what if I want a private setter?
Rather than writing this:
public class C {
private var _i: Int = 0
public var i: Int {
get {
return self._i
}
}
}
You can use this nifty syntax, to specify a seperate access level for the setter:
public class C {
public private(set) var i: Int = 0
}
Now isn't that clean?
There is no need to create setters and getters for stored properties in Swift and you shouldn't create them either.
You can control the accessibility of getters/setters separately when you declare a property.
public private(set) var name: String // public getter, private setter
If you want to implement some custom logic in your setter, you should use property observer, i.e. didSet/willSet.
var name: String {
didSet {
// This is called every time `name` is set, so you can do your custom logic here
}
}
You will hardly come across the need to create your own getters and setters.
Swift's computed property lets you use getters and setters in a very simple way.
Eg: below defined is a computed property circleArea that returns area of circle depending on radius.
var radius: Float = 10
var circleArea: Float {
get {
return .pi * powf(radius, 2)
}
set {
radius = sqrtf(newValue / .pi)
}
}
While you can observe a stored value and perform some task using property observers:
var radius: Float = 10 {
willSet {
print("before setting the value: \(value)")
}
didSet {
print("after the value is set: \(value)")
}
}
radius += 1
// before setting the value: 10.0
// after the value is set: 11.0
However if you feel like using getter setter, you can define appropriate functions for that. Below defined is an extension on Integer to get and set properties value.
extension Int {
func getValue() -> Int {
return self
}
mutating func setValue(_ val: Int) {
self = val
}
}
var aInt: Int = 29
aInt.getValue()
aInt.setValue(45)
print(aInt)
// aInt = 45
How do I properly type Classes that implement interfaces?
Example code:
interface IPlugin{
name:string;
}
class SomePlugin implements IPlugin{
name;
constructor(){
this.name = 'Sam';
}
}
const arrayOfClass:IPlugin = [SomePlugin];
// Ther error :
/*
Type 'typeof SomePlugin[]' is not assignable to type 'IPlugin'.
Property 'name' is missing in type 'typeof SomePlugin[]'.
*/
How should I go about this?
Create an interface that describes objects that will instantiate objects that implement IPlugin. You can do this by using a new signature:
interface IPluginConstructor {
new(...args: any[]): IPlugin;
}
Now type arrayOfClass as an array of IPluginConstructors:
const arrayOfClass: IPluginConstructor[] = [SomePlugin];
Note the [] in the type. That was absent in the question.
Sidenote
If you look closely, the type of name is any in SomePlugin... it's been set as any because the type was implicitly typed as any and string is assignable to any. That means the following code compiles:
const s = new SomePlugin();
const num: number = s.name; // this compiles... sad! :(
You should type that either explicitly...
class SomePlugin implements IPlugin {
name: string;
constructor() {
this.name = 'Sam';
}
}
...or implicitly...
class SomePlugin implements IPlugin {
name = 'Sam';
}
I recommend you enable the noImplicitAny compiler flag to help catch these kind of mistakes in the future.