As I know, it's basing on Guru for vim-go to find the implementations or usage which needs to compile the whole project as a premise. Otherwise, GoLand doesn't need to do that, but how?
While this task may look rather trivial, GoLand uses some tricks to perform it more efficiently. Let's go step by step to explore how it works.
When one opens a project for the first time, the IDE performs so-called indexing. In particular, it stores all the method and method spec names as well as the number of their parameters.
At the beginning of the search, GoLand takes method specs of the interface and finds one with the biggest number of parameters. This is a performance optimization. The idea behind it is that methods with many parameters occur less often in the code, so the IDE needs to check just a few of them.
It's time to use the index. For the chosen method spec, the IDE finds all corresponding methods. The scope is taken into account, so for a private interface, for instance, it's much smaller.
For each method, GoLand resolves its type and checks whether it implements the interface. This is the moment when all interface's method specs are taken into account.
Not only structures can implement interfaces but other interfaces, too. As the next steps, the IDE looks for all corresponding method specifications, that is, method specifications with the same name and number of parameters. There's a separate index that's responsible for this.
For each method spec, its interface is taken and checked. No resolution is involved this time as it's enough to traverse a syntax tree up to find an interface of an arbitrary method spec.
That's basically the algorithm. There are a few more implementation details to make it works faster, but they don't affect results.
GoLand relies on the IntelliJ Platform and a set of custom written tooling bundled as a custom language plugin on top of it to handle indexing, parsing, navigation and editing code.
(This question regards search/6.)
I was wondering if there is a way -rather than manual tracing- to pause the execution of search/6 every time a new solution for a single variable was found?
I would like to accomplish this to further investigate what is happening during search in constrained models.
For example, if you are trying to solve the classic sudoku problem, and you have written a set of constraints and a print method for your board, it can be useful to print the board after setting the constraints, but before searching, in order to evaluate the strongness of your constraints. However, once search is called to solve the sudoku, you don't really have an overview of the single results being built underneath unless you do a trace.
It would be very useful if something was possible in the likes of:
(this is just an abstract example)
% Let's imagine this is a (very poorly) constrained sudoku board
?- problem(Sudoku),constraint(Sudoku),print(Sudoku).
[[1,3,_,2,_,_,7,4,_],
[_,2,5,_,1,_,_,_,_],
[4,8,_,_,6,_,_,5,_],
[_,_,_,7,8,_,2,1,_],
[5,_,_,_,9,_,3,7,_],
[9,_,_,_,3,_,_,_,5],
[_,4,_,_,_,6,8,9,_],
[_,5,3,_,_,1,4,_,_],
[6,_,_,_,_,_,_,_,_]]
Now for the search:
?- problem(Sudoku),constraint(Sudoku),search_pause(Sudoku,BT),print(Sudoku,BT).
[[1,3,6,2,_,_,7,4,_],
[_,2,5,_,1,_,_,_,_],
[4,8,_,_,6,_,_,5,_],
[_,_,_,7,8,_,2,1,_],
[5,_,_,_,9,_,3,7,_],
[9,_,_,_,3,_,_,_,5],
[_,4,_,_,_,6,8,9,_],
[_,5,3,_,_,1,4,_,_],
[6,_,_,_,_,_,_,_,_]]
Board[1,3] = 6
Backtracks = 1
more ;
Using existing Visualization tools
Have a look at the Visualization Tools Manual. You can get the kind of matrix display you want by adding a viewable_create/2 annotation to your code, and launching a Visualisation Client from TkECLiPSe's Tools-menu.
Using your own instrumented search routine
You can replace the indomain_xxx choice methods in search/6 with a user-defined one where you can print information before and/or after propagation.
If that is not enough, you can replace the whole built-in search/6 with your own, which is not too difficult, see e.g. the ECLiPSe Tutorial chapter on tree search or my answer to this question.
Tracing using data-driven facilities
Using ECLiPSe's data-driven control facilities, you can quite easily display information when certain things happen to your variables. In the simplest case you do something on variable instantiation:
?- suspend(printf("X was instantiated to %w%n",[X]), 1, X->inst),
writeln(start), X=3, writeln(end).
start
X was instantiated to 3
end
Based on this idea, you can write code that allows you to follow labeling and propagation steps even when they happen inside a black-box search routine. See the link for details.
I was wondering, does visual studio have a feature such that I gave it a 2 method names and it then works out if at somewhere along the call stack the first method is called by the second (statically, without having to debug).
e.g.
Say I have a method FireBullet, and I want to see if IsOutsideWestBoundary can be invoked at some point
FireBullet()->HitTest()->CheckBoundaries()->IsOutsiteWestBoundary()
You can see that FireBullet can eventually cause IsOutsideWestBoundary to be invoked at some point.
I understand this can potentially become a very large problem, especially with deep call stacks and multiple methods called at each level, but still, for relatively small call stacks depths, this could be very useful.
Surely something like this must exist?
Thanks
Thomas
The Visual Studio extension NDepend can do that. It lets write code rules and code queries through C# LINQ queries. The following LINQ code query, executed live in Visual Studio, answers your need:
from m in Methods
where m.Name == "FireBullet()"
let depth0 = m.DepthOfIsUsing("MyNamespace.Program.IsOutsiteWestBoundary()")
where depth0 >= 0 orderby depth0
select new { m, depth0 }
Notice that the code query result also provides the depth of call. It can be stored in your NDepend project, and it can be transformed into a rule by adding the prefix warnif count > 0.
This query gets inspired from the query generated by NDepend when right clicking a method and Select Methods ... that call me (directly or indirectly).
If you click the button Export to Graph you get such call graph (more info on this here):
A 14-day full featured trial is available here.
Disclaimer: I work for NDepend.
I see a lot of javafx code something like this:
private Button getButton(){
Button myButton = new Button("A button");
myButton.setOnAction...
}
private HBox toolbar(){
Button file = new Button("File");
Button edit = new Button("Edit");
Button props = new Button("Properties");
HBox toolbarArea = new Hbox();
toolbarArea.getChildren().add(file, edit, props);
}
I'm interested in an explanation of why this is done (which I haven't found).
The small method approach works well for internet demo code
Rather than using small methods to define UI elements, the alternatives are:
A very long method unless the application is completely trivial.
FXML defined UI (usually preferred for non-trivial examples, but verbose and unnecessary for small demonstrations).
Separate enclosing objects and classes (sometimes overkill if only aggregation of existing controls is required).
Small methods decrease dependencies on pre-declared objects and program state. Usually the small methods are self-contained and any inputs to them are in their parameter list - it's easier to read and understand them without needing to understand a lot of contextual information and it is also easier to unit test the methods or apply the methods to a more functional programming style, reuse the methods in lambda calls, etc. The names of the small methods also make them self-documenting, so the code is more readable without adding additional comments.
So, in a lot of small, example JavaFX applications you see on the internet, you will find the approach of small methods to describe UI elements, though such an approach is not always the one you should use when you are building larger applications.
Using small methods for UI component definition is an example of an extract-till-you-drop method of programming. Of course, as you can see in the comments on the linked extraction blog, everything is debatable and opinionated, so use your best judgement, but when in doubt, I'd argue in favor or method extraction, not just in the UI definition code, but in your functional code as well.
A concrete example
Take a look at the discussion of JavaFX programming style in the comments on this blog. This is based on this original clock app sample, which does not use small methods, and an updated clock app sample, which is built around many small methods. Per's Lundholm's comment on the original code was this:
A typical sign of not doing it right is when you write comments. Don’t write comments in your code, write code that reads well without comments!
I read you code and I think it is virtually unreadable, with all respect. It is a long method sprinkled with constants that carries little or no meaning. If I am given such a code to change, be it fix a small bug only, I start to extract method ’til I drop. It is the fastest way of understanding code.
I suggest you review both sample code bases and decide which you would prefer to maintain. My guess is that you will decide the version with many small methods would be easier to read and maintain.
Use declarative FXML and CSS for larger applications
Also keep in mind, that for many larger applications, use of FXML and CSS is preferred over java code to define and style the UI elements - this is because a large part of defining a UI is often easier to maintain using a declarative syntax rather than a procedural or functional syntax, and FXML is declarative by it's nature (plus it is fully tooled via SceneBuilder and IDE FXML support). Study the SceneBuilder code base for an example of how to use FXML and CSS to define larger UIs.