Could someone explain the static fields declared in the interface org.eclipse.gef.EditPolicy(e.g COMPONENT_ROLE,CONNECTION_ROLE,CONNECTION_ENDPOINTS_ROLE etc).I have gone through the javadocs of the interface but the explanation is not clear.
AFAIK they have no real meaning. When you install an edit policy you must give it a unique name, but I have never code that uses these name. You can freely ignore them :-)
Related
I have a Kotlin Library into which I integrated the usage of Detekt static code linting. Most of the rules are clear to me and I fixed all the issues with my code except for one:
There is a rule called LibraryEntitiesShouldNotBePublic, which makes no sense in my opinion. It tells me for every public class, that it should not be public, but of what use is a library without any public classes.
I must admit I am rather new to Kotlin, coming from Java, so I might miss some language feature here.
Any hints would be greatly appreciated. Thanks.
I am curious what the rules are for categorizing Monticello extension methods. I notice (in the Pharo image) some are in all lowercase like *package-name while others are in normal case like *Package-Name. Also I am curious about sub categorization to add a "real" category after the package name, like *Package-Name-accessing, for example when extending with accessors some class, is this supported or dangerous and possible to break?
Update: if I did something wrong, I would like to know why instead of downvotes without comment.
Package name comparison is case-insensitive. Traditionally, Smalltalk uses lowercase categories. You're free to use either.
There is no harm in adding '-foo-bar baz' suffixes to the category name.
Note that this is not built into Monticello. It uses PackageInfo to determine which definitions are part of a given package. Browsing PackageInfo is enlightening.
Also, name-based matching is only the default. A PackageInfo subclass can override this, but this is done very rarely.
What is the recommended way to define private and protected methods in Objective-C? One website suggested using categories in the implementation file for private methods, another suggested trailing underscores, or XX_ where XX is some project-specific code. What does Apple itself use?
And what about protected methods? One solution I read was to use categories in separate files, for example CLASS_protected.h and CLASS_protected.m but this seems like it could get very bloated. What should I do?
There are three issues:
Hiding from compiler.
That is, making it impossible for someone else to #import something and see your method declarations. For that, put your private API into a separate header file, mark that header's role as "Private" in Xcode, and then import it in your project where you need access to said private API.
Use a category or class extension to declare the additional methods.
Preventing collisions
If you are implementing lots of internal goop, do so with a common prefix or something that makes a collision with Apple provided (or third party) provided methods exceedingly unlikely. This is especially critical for categories and not nearly as critical for your leaf node subclasses of existing classes.
Post the link for the site suggesting leading underscores, as they are wrong, wrong, wrong. Leading underscores are used by the system to mark private API and you can run into collisions easily enough.
Hiding from the runtime.
Don't bother. It just makes debugging / crash analysis harder and anyone determined enough to muck around at the runtime will be able to hack your app anyway.
There are no "real" private methods in Objective C, as the run-time will allow, via documented public APIs, access any method in any class by using their string names.
I never do separate interface files for "private" methods, and let the compiler complain if I try to use these any of these methods outside of file scope.
The XX_ seems to be the ad hoc means to create a pseudo namespace. The idea is to read Apple's docs and the docs of any frameworks you might use at any time in the future, and pick an XX prefix that none of these others is ever likely to use.
I'm really frustrated with this one. I'm trying to extend a C# created interface in C++/CLR. The interface has one method and I've declared it in my class, but the compiler keeps telling me that I must still provide an implementation for the interface method. What more can I do? What am I missing!?
Does anyone have any examples of how to extend a C# interface in CLR?
I figured it out! I needed to make the implementation of elements virtual. I hope this helps other people with this same issue.
I read somewhere that interfaces can have member variables.
Static final constants only, can use
them without qualification in classes
that implement the interface. On the
other paw, these unqualified names
pollute the namespace. You can use
them and it is not obvious where they
are coming from since the
qualification is optional.
I am not quite understood by what they meant? Any help?
What you read is incorrect. Interfaces cannot have member variables.
In VB.Net the only allowable definitions inside an interface are
Properties
Methods
Events
Type Definitions (not legal in C#)
I'm not entirely sure what the above paragraph is referring to. Based on the text though it sounds like it's refering to Java. They phrase static and final is most often associated with Java code and not .Net (static and readonly).
Can you give us some more context on it?
If you define a constant like this inside a class MyClass:
public static final int MY_CONSTANT = 1;
you can refer to it from other classes as MyClass.MY_CONSTANT, using the MyClass qualifier. This hints the location of the constant definition.
If you define such a constant in an interface MyInterface, you still can refer to it using MyInterface.MY_CONSTANT. However in the classes implementing MyInsterface you can simply use MY_CONSTANT without "MyInterface" prefix.
It may look convenient (less key strokes), but may lead to confusion because without qualifier (prefix) it is not clear where the constant was originally defined.
Adding member variables to interfaces would be bringing in MI through the back door.
Not available in .NET, sorry.
I wish it were there though.