If you take a look at the File struct it has a Read() and Write() function that is exactly the same as io.Writer and io.Reader interface Read() and Write() functions. But the package io is no where to be found in File package (not imported). Does this mean that interfaces do not at all have to be imported to be used? As long as the Read() definition is the same as the interface it can then be implied that it is part of the io.Writer or io.Reader interface?
io: http://golang.org/pkg/io/
os: http://golang.org/pkg/os/
Package os does not import package io as the io.Reader interface is not used in package os.
The type *File happens to implement io.Reader because it has a Readmethod with the right signature. This implements relation is implicit and it is neither needed nor possible to make this explicite (e.g. like in Java with implements ISomeThing).
You asked: "Does this mean that interfaces do not at all have to be imported to be used?" and the formal answer is: Of course not! If you want to use io.Reader you have to import "io".
But implementing/satisfying an interface is not an use of this interface: Any type implements any interface (even future ones which have not been invented jet) just by having the right methods.
Exported entities are constants, variables and types. To use them, ie. to refer to such exported entities, one has to use their [qualified] name, while the qualifier is the basename of the package which exports them. That also implies using an import statement of such package. IOW, binding exported entities in a file scope is [strictly] explicit. No import == no access to exported stuff.
OTOH, implementing an interface is specified to be implicit:
A type implements any interface comprising any subset of its methods and may therefore implement several distinct interfaces. For instance, all types implement the empty interface:
interface{}
Related
Where is the implementation of that function?
is a macro function
I searched the source code but couldn't find it
GTK_IS_ROOT() is defined by the G_DECLARE_INTERFACE (GtkRoot, gtk_root, GTK, ROOT, GtkWidget) at https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gtk/gtkroot.h#L35 macro. This is a GObject macro and GTK uses GObject extensively.
Basically: when writing GObject classes or interfaces, you need to write quite a bit of boilerplace to implement inheritance right, ideally in a way that helps with ABI stability. GObject provides macros that make it easier for you: G_DECLARE_FINAL_TYPE(), G_DECLARE_DERIVABLE_TYPE() and G_DECLARE_INTERFACE() are macros that respectively do the declaration for a final class (which can't be subclassed), a derivable class, and an interface.
One of the things that you often want to do with runtime inheritance, is to perform certain checks related to the type of a certain parameter or variable. The aforementioned macros help out with that by generating some extra macros to implement such functionality.
Given a namespace Xxx (for example Gtk) and a type name Yyy (for example Root) it will provide an XXX_IS_YYY(var) macro to check if the given variable var is truly an instance of the class (i.e. it implements the instanceof() operator you might know of other languages)
In Java package protected access was very handy, because it allowed to write modular code. This is not possible with Kotlin unless you stick all those classes into one file and put Private on all of them or by implementing Internal in a separate Module. But I don't like this solutions. Putting lot of stuff in one file is not readable and another problem is that you cannot test any Method/Class that is not Public. Is there another solution?
No, package-protected access is not supported.
You should use internal in Kotlin. This restricts access to the same module, a logical unit of files compiled together to an artifact.
The motivation for not providing a package-protected visibility specifier is as follows, from a Kotlin developer:
The motivation for not having package protected access is very simple: it does not provide any real encapsulation. Any other module in the system can define classes in the same package as your complex independent component and get full access to its internals. On the other hand, classes with internal visibility cannot be accessed from any module other than the one where they are defined.
And you definitely can test methods/classes that have internal access: the tests of a module have full access to internal declarations of that module.
I am currently reading "Scala Programming, 2nd ed." (OReilly 2015) by Wampler/Payne, and they mention Package Objects as a means to expose abstractions.
On p.504 however, they mention
Package objects
An alternative to finegrained visibility controls is putting all implementation constructs in a protected package, then using a top-level package object to expose only the appropriate public abstractions. For example, type members can alias types that would otherwise be hidden [...]"
Now my question is: is there a way to declare said protected package as protected once, without having to declare it for every every class/object down the hierarchy? And if so, how?
Or did I simply misunderstand the authors?
As clarification: I am currently working on a library which is supposed to expose minimal API in order for $colleagues to have to actually touch internals to make fundamental changes or to have to do configuration via config-files.
Second question: is this the right path to go? Should I maybe go another route?
Doing a little research of my own, it seems to me that it's not possible in Scala to declare a package to be entirely private. (You can check out the Language Specification here, where there is no mention of being able to qualify a package declaration with 'private' or similar)
I think what the authors are suggesting is the following, roughly translated:
Instead of using finegrained controls, such as declaring some of your class members private or protected and leaving the rest public, you could make all of the important classes in your package completely private (as in private class/trait/object P {...}). Then, you can put the important public details of the API into the package object, exposing these private innards. For example, if you need to expose a protected type, you can use type aliasing for that...
in scala i need to implement something similar to python metaclasses. in my case the goal of using the metaclasses is usually to create a registry of all the subclasses of a particular base class - that is, a mapping from say a string representation of the class to a reference to the class. in python it's very convenient to put a metaclass on the base class so that nothing special needs to be done on every subclass. i'm looking to do something similar in scala. is there any way to emulate metaclasses, or otherwise do this a different way? thanks!
If you know the fully qualified name of the class, you can load it using the usual Java reflection methods in java.lang.Class, namely Class.forName(String fqClassName). Given the resulting instance of Class, instantiation is easy only if there's a zero-argument constructor, otherwise you get entangled in the messy world of all the Java reflection types.
If you want a kind of "discovery" where classes unknown at compile time and whose names are not supplied as an input or parameter of the program in some way, then the classloader approach is probably the only answer.
There's nothing similar to python's metaclasses. The registry you speak of might be possible using custom class loaders or reflection.
Interface (or an abstract class with all the methods abstract) is a powerful weapon in a static-typed language such as C#, JAVA. It allows different derived types to be used in a uniformed way. Design patterns encourage us to use interface as much as possible.
However, in a dynamic-typed language, all objects are not checked for their type at compile time. They don't have to implement an interface to be used in a specific way. You just need to make sure that they have some methods (attributes) defined. This makes interface not necessary, or at least not as useful as it is in a static language.
Does a typical dynamic language (e.g. ruby) have interface? If it does, then what are the benefits of having it? If it doesn't, then are we losing many of the beautiful design patterns that require an interface?
Thanks.
I guess there is no single answer for all dynamic languages. In Python, for instance, there are no interfaces, but there is multiple inheritance. Using interface-like classes is still useful:
Interface-like classes can provide default implementation of methods;
Duck-typing is good, but to an extent; sometimes it is useful to be able to write isinstance(x, SomeType), especially when SomeType contains many methods.
Interfaces in dynamic languages are useful as documentation of APIs that can be checked automatically, e.g. by development tools or asserts at runtime.
As an example, zope.interface is the de-facto standard for interfaces in Python. Projects such as Zope and Twisted that expose huge APIs for consumption find it useful, but as far as I know it's not used much outside this type of projects.
In Ruby, which is a dynamically-typed language and only allows single inheritance, you can mimic an "interface" via mixins, rather than polluting the class with the methods of the "interface".
Mixins partially mimic multiple inheritance, allowing an object to "inherit" from multiple sources, but without the ambiguity and complexity of actually having multiple parents. There is only one true parent.
To implement an interface (in the abstract sense, not an actual interface type as in statically-typed languages) You define a module as if it were an interface in a static language. You then include it in the class. Voila! You've gathered the duck type into what is essentially an interface.
Very simplified example:
module Equippable
def weapon
"broadsword"
end
end
class Hero
include Equippable
def hero_method_1
end
def hero_method_2
end
end
class Mount
include Equippable
def mount_method_1
end
end
h = Hero.new
h.weapon # outputs "broadsword"
m = Mount.new
m.weapon # outputs "broadsword"
Equippable is the interface for Hero, Mount, and any other class or model that includes it.
(Obviously, the weapon will most likely be dynamically set by an initializer, which has been simplified away in this example.)