When we declare a class as static, we need to explicitly declare each member as Static, otherwise compiler error.
But, When we declare an interface, we do not need to declare all members as public, they are public by-default.
Any idea why such behavior?
public, protected, internal, protected internal, and private, are all access modifiers. Every type in C# has a default accessibility level, so you needn't explicitly define them.
The static keyword is a modifier, but it is not an access modifier. Most modifiers require explicit declaration.
As to why they made it compulsory to define your members in a static class as static, I'm not certain. It could be because static classes can contain non-static (i.e. instantiable) nested types; it might cause problems if those were being declared as static by default.
Related
The question may be a bit confusing, and is best illustrated by an example:
unit Test
interface
type
TestClass = class()
Splitter1: TcxSplitter;
procedure SomeMethod();
end;
implementation
uses
cxSplitter;
// Locally-declared child type
type
TcxSplitterAccess = class(TcxSplitter);
procedure TestClass.SomeMethod()
var
pos: integer;
begin
// Access to protected field FPositionBeforeClose by casting
pos := TcxSplitterAccess(Splitter1).FPositionBeforeClose;
end;
Notice in the implementation section that there is a type TcxSplitterAccess being declared as a child of the TcxSplitter class. In the method SomeMethod(), belonging to the class TestClass, a TcxSplitter object is cast to the locally-declared TcxSplitterAccess class, and then a protected field is accessed on that object.
This is surprising to me as someone coming from a background of languages like Java, C++, C#, etc. In those languages, it is possible to access protected data in an object so long as you are doing it from within that object's type or an inherited type. For example, a method inside of a class ClazzA can access the private fields of other ClazzA objects since access is enforced at the type level rather than the instance level. Declaring a class locally in these languages would not give the containing class access to the local class' protected data (edit: As pointed out in the comments, this is actually not true at least for Java).
In this example, however, the type TestClass is directly accessing a protected field on the TcxSplitter object by first casting to the TcxSplitterAccess type. I am having trouble finding documentation on why this "trick" works. Does Delphi handle access levels fundamentally differently to Java-like languages and allows this sort of thing? Regardless, why does this trick work?
While I stumbled onto this behavior by using a nested, inherited class in order to access fields on the parent class (which breaks encapsulation, and I shouldn't do), the use of inheritance here is unnecessary. If the nested class did not inherit from a class, but instead had its own protected fields defined, TestClass would still be able to access those protected fields.
A unit has implicit-friendship semantics within itself. Types declared in the same unit are "friends" of each other (similar to friend in C++), and so can access each other's private and protected members (but not strict private or strict protected members).
So, in this case:
TcxSplitterAccess derives from TcxSplitter, so TcxSplitterAccess inherits all of the protected (but not private) members of TcxSplitter via normal class inheritance.
TestClass is declared in the same unit as TcxSplitterAccess, so TestClass has access to all of the protected members of TcxSplitterAccess, including the protected members of TcxSplitter (and the protected members of its ancestors).
FPositionBeforeClose is protected in TcxSplitter.
So, that is why TestClass.SomeMethod() is able to access FPositionBeforeClose when type-casting the Splitter1 object to TcxSplitterAccess.
This is covered by the Delphi documentation:
Private, Protected, Public, and Published Declarations
Classes and Objects (Delphi): Visibility of Class Members
What storage policy will variables declared in a local function inside a class have, static or automatic?
The "storage policy" is the lifetime. It will always be automatic. Section 8.6 of IEEE 1800-2012 states
The lifetime of methods declared as part of a class type shall be automatic. It shall be illegal to declare a
class method with a static lifetime.
You can declare a class method as being static, but in that context it means something entirely different. Section 8.10 states:
A static method is different from a task with static lifetime. The former refers to the lifetime of the method
within the class, while the latter refers to the lifetime of the arguments and variables within the task.
So, a static method can be called even if no objects of that class exist.
The local or protected attribute of a class member has no effect on the storage policy. It only affects the visibility of the identifier used to access the members.
That being said, the storage policy of a class member also affects the visibility of that identifier. So both features have the ability to restrict access, but for different reasons.
For example, you can never access an automatic variable from outside the scope of where it was declared. It does not matter if that scope is a class method, or a simple task. And it does not matter what the default lifetime of that scope was.
Conversely, if you declare a static variable in a scope, you might be able to access that variable from outside that scope, but you need to consider all the other visibility rules.
I've been searching over access control guides and tutorials, but couldn't find any information.
Imagine you have some Swift module with class A implementation. This class is internal. It has some property, let's call it prop.
The question is: what changes if I set it's access level from internal to public?
internal class A {
public var prop: String?
}
I saw examples of such code, but don't understand, why. Is it just useful when you decide to make your type public, so you don't need to change access level of properties and methods? Or it has some other practical use like giving someone else access while the type is still internal?
As per Apple doc
A public variable cannot be defined as having an internal,
file-private, or private type, because the type might not be available
everywhere that the public variable is used.
More about Internal -
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.
So no use of declared public inside internal class.
There is no difference in overall functionality: since your class is internal, it cannot be exposed in public members, say public var propA : A or public func f(a:A) so the fact that its members have public visibility makes no difference.
However, by using public you avoid repeating yourself: you have already designated the whole class internal, so you don't need to designate all its individual members as internal.
It also becomes helpful if you decide to convert the class to public at some later time, because you change only one internal modifier to public.
Specifically in regards to member variables, is there a difference between the following in Swift 3? In both cases, Foo is accessible by all code in that same file. Same thing with the implicitly-scoped 'laa' property, which seems to contradict the documentation.
If you define a type’s access level as private or file private, the default access level of its members will also be private or file private.
However, in both cases below, 'laa' is accessible from other classes in the same file implying that it is fileprivate, not private as the docs say the first one should be.
private class Foo
{
var laa:String
}
fileprivate class Foo
{
var laa:String
}
As said in this Q&A – there's no difference in the access levels between a top-level private and fileprivate declaration. private simply means that it's accessible only in the enclosing scope1, and at the top-level – the file is that scope.
Regarding the documentation comment:
If you define a type’s access level as private or file private, the default access level of its members will also be private or file private.
I would say this is incorrect, or at the very least misleading in the case of private. The scope in which a given type's members are visible is by default the scope that the type declaration itself is visible in (with the exception of access levels higher than internal).
Therefore the scope in which a private type's members are accessible is by default the enclosing scope that defines that type. At the top level, that's the file.
It's probably simpler just to say that type members default to being internal. Being declared in a type with a lower access level than this (such as private or fileprivate) just prevents the members from being visible outside of these access levels (as it makes no sense to refer to a given type's member without being able to see the type itself).
1. Note that in Swift 4, as per SE-0169, extensions of a given type that are declared in the same source file as the type have the same access control scope as the scope of the type declaration. Therefore they can access private members of the type.
I created two classes Content and Bucket. Bucket contains an array of Content objects and exposes that via a public property. However, when I do so, I receive the error:
Property cannot be declared public because its type uses an internal type
Any thoughts on why this is raising an error?
You have to declare the access level of the Content class public as well.
public class Content {
// some code
}
As stated in the documentation:
A public variable cannot be defined as having an internal or private
type, because the type might not be available everywhere that the
public variable is used.
Classes are declared as internal by default, so you have to add the public keyword to make them public.
A similar rule exists for functions as well.
A function cannot have a higher access level than its parameter types
and return type, because the function could be used in situations
where its constituent types are not available to the surrounding code.
Content must be declared as public too:
public class Content {
…
}
Depending on your use-case you might declare Bucket as internal, too. Just omit the public keyword in this case.
My issue was a namespace problem.
I had declared an enum called Data and that was mucking with the Swift Data class, especially an imageData: Data property within a Core Data model.