Just to be sure, has Dart removed explicitly defining an interface now in favor of implicitly defining it via abstract?
I see it mentioned in Dart and Interface Segregation Principle, however I'm also finding a lot of content still referencing the explicit definition, such as When to use interfaces in Dart?
Yes. The interface keyword was removed from Dart. Instead all classes have implicit interfaces. So if you want to define an interface you can use an abstract class instead.
See this blog post from 2012 about eliminating the interface keyword.
Related
It's said in the documentation that
In native JS types, all concrete definitions must have = js.native as body. Any other body will be handled as if it were = js.native, and a warning will be emitted. (In Scala.js 1.0.0, this will become an error.)
And that's correct. However I found that I can omit body at all (thus making definition abstract) and there is no warning and generated js seems to be the same as with js.native body.
So my question is: what's the difference between abstract definitions and concrete definitions with js.native body?
The difference is that an abstract definition is abstract, and, well, a concrete definition (with = js.native) is concrete, from Scala's type system point of view.
But then what? From the use site of the class or trait, is doesn't make a difference. This is similar to normal Scala (or Java): when using a method, it doesn't matter whether it is abstract or not.
So the real difference is on the definition site. In theory, choosing abstract or concrete boils down to this criterium:
Does this method have an actual implementation in JavaScript code (not only a documented contract)? If yes, it should be concrete; if not, it should be abstract.
Practically and pragmatically, note that an abstract method can only appear in an abstract class or a trait, and must be implemented in a subclass/subtrait.
In terms of facade, in a native class, most methods should be concrete (if not all). That is because in JS, classes usually have concrete methods. In fact, abstract methods do not even exist in JS. The only reasonable case of defining an abstract method in a native class is if the "contract/documentation" of that class stipulates than a) it should be subclassed and b) subclasses should implement a particular method (not implemented in the superclass). This documented contract is as close as JS can get to abstract methods.
In JS traits, methods should usually be abstract (and the traits themselves be #ScalaJSDefined rather than #js.native). That is because traits/interfaces themselves do not even exist in JS. They only exist by their documented contract, which specifies what methods must/will be implemented by classes that satisfy this interface.
The only reasonable use case for concrete methods in (#js.native) JS traits is for DRYness. If several classes of a native API implement the same (large) set of methods, it can be reasonable to gather those methods in a native trait. In order not to have to repeat their definitions in all classes, they can be made concrete in the trait (if they were abstract, the classes would need to provided a concrete version to satisfy the contract). Note that such traits cannot be extended by non-native (#ScalaJSDefined) JS classes.
In the cases where you don't want to figure out the above "theoretical" criterium, use the following rule of thumb:
Is the method in a native JS class? If yes, it is almost certainly concrete.
Is it in a JS trait? If yes, it is almost certainly abstract (and the trait should be #ScalaJSDefined).
I was converting text to ASCII number in Powershell and having trouble with ToByte(). When I looked at the methods for string, I see that some of them show up with an interface prefix, whilst most don't.
Can anyone tell me the difference between these defintions? Why ToByte() starts with IConvertible, but PadLeft() doesn't? Any why ToString() has both of these notations?
Because those methods with the interface name are Explicit Interface Implementations.
If a class implements two interfaces that contain a member with the
same signature, then implementing that member on the class will cause
both interfaces to use that member as their implementation.
If the two interface members do not perform the same function,
however, this can lead to an incorrect implementation of one or both
of the interfaces. It is possible to implement an interface member
explicitly—creating a class member that is only called through the
interface, and is specific to that interface. This is accomplished by
naming the class member with the name of the interface and a period.
Explicit implementation is also used to resolve cases where two
interfaces each declare different members of the same name such as a
property and a method.
You can also see this listed in the String class documentation under Explicit Interface Implementations.
I writing a small Snake game in Lazarus, and Lazarus complains when I write
type
ISegment = interface(IRenderable, IMover)
end;
When I'm trying to achieve is to make ISegment a combined interface, but it doesn't seem to work. Does Lazarus not support multiple interface inheritance?
There is no multiple inheritance supported in the language. A class cannot be derived from multiple base classes. An interface cannot be derived from multiple base interfaces.
What you can do however, is have a class that implements multiple interfaces. Like this:
type
TMyClass = class(TInterfacedObject, IFoo, IBar)
....
end;
It does, you just need a better reading skill to understand this (look at the syntax diagram, in the heritage part). class type identifier is not stated as optional, but implemented interface does. It's roughly read as:
"A class may extend a base class and implements as many interfaces as possible. When an interface is about to be implemented, the base class must also be specified. The other way around does not apply, you can perfectly have a class extends a base class without specifying any interface"
The answer is no, Pascal is not supposed to support multiple inheritance so I don't see why it should do a different thing for interfaces then
As explained in previous answer, you still can implement several interfaces in a class
This question has been asked (and probably answered) in the old Haxe forums on babble ... but it appears that that entire forum system no longer functions. Therefore, I'm asking here:
In Haxe, I need to declare an "Interface" to a class which includes a static function, "instance()." But when I do so:
You can't declare static fields in interfaces
So I remove the word "static" from public function instance() [...], and I get this:
Field instance needed by [...] is missing.
Apparently a "Catch-22." But there obviously must be some easy solution. What is it?
As you stated the language doesn't allow for static fields on interfaces. The choice is intentional. Another thing that doesn't exist is inheriting static fields.
There are several ways to structure your code to avoid such usage that in my point of view it doesn't give you many advantages. A factory pattern or DI approach (I suggest the minject library) seems the most obvious.
Given the comment below go for a typedef instead of an interface:
typedef GetInstance = Void -> Void;
You can pass that typedef around the same as an interface with the advantage that you can use both static and instance methods to satisfy that signature.
Check out the Singleton library. Any class that implements Singleton will automatically declare a static "instance" variable and corresponding getter function.
Note: as of this writing, the Haxelib version (1.0.0) is out of date. Download the Git version instead.
I just started learning GTK. I was going through source code of gtk+3.0.0, I found implementation of _get_type() methods for some gtk object types but some do not have an implementation of this method e.g GtkRange. Is there any reason for this? As far I understood from GObject Reference Manual, _get_type() method registers object type in type system.
the get_type() function is needed for all types registered as a GType. GObject (the library) provides convenience macros to generate the correct get_type() function implementation taking into account things like thread-safe initialization, or dynamic type registration.
the macro that is used for GObject (the type) subclasses is G_DEFINE_TYPE(), but inside GTK+ you will also find G_DEFINE_TYPE_WITH_CODE(), used generally when the type also implements interfaces; G_DEFINE_ABSTRACT_TYPE() and G_DEFINE_ABSTRACT_TYPE_WITH_CODE(), used for abstract types; and, more recently, G_DEFINE_TYPE_WITH_PRIVATE() and G_DEFINE_ABSTRACT_TYPE_WITH_PRIVATE(), which define GObject subclasses with private data, avoiding the call to g_type_class_add_private() inside the class initialization function.
boxed types (GType wrappers around Plain Old Structures) also have G_DEFINE_BOXED_TYPE(), and interface types have G_DEFINE_INTERFACE().
more information is available in the API reference for GObject:
https://docs.gtk.org/gobject/func.DEFINE_TYPE.html