I am trying to write some basic MongoDB custom queries in Kotlin.
I've seen nearly everywhere that people use a method addCriteria:
val query: Query = Query()
query.addCriteria(Criteria.where("field1").exists(true)))
But it seems there is no method addCriteria in Query which I use: org.springframework.data.mongodb.repository.Query
I am very confused. Cannot find any explanations on how to write custom MongoDB queries in Kotlin with Spring Data except using this method.
So, I was very close to the problem's solution. I really used wrong Query, despite it's path looks really logical. I needed this one: org.springframework.data.mongodb.core.query.Query.
I used org.springframework.data.mongodb.repository.Query, which is Query annotation, not the class
I would like to write Intellij plugin that can display values returned by class def() in python. I would like those values to be evaluated as much as possible and done by static analysis. I need this to work only for very simple expressions in one particular use case.
We have class definitions in our python code base that consist of a lot of very simple def()s.
All the defs are just one return statement returning very simple expression.
All of the code follows the same pattern and uses very few python operator.
the code is long and really hard to follow.
After few jumps "to definition" within this class I can't remember where I am anymore.
I am hoping that some intellij plugin can lessen the pain.
So for example. this is short and very simplified code fragment. hopefully it will be enough to demonstrate the problem.
class SomeClass(object):
def __init__(self, param):
self.param = param
def a(self):
return self.param + 1
def b(self):
return self.a + otherfunc()
def c(self):
return self.b + 3
I would like the plugin to display the following:
class SomeClass(object):
def __init__(self, param):
self.param = param
def a(self): # = param + 1
return self.param + 1
def b(self): # = param + 1 + otherfunc()
return self.a + otherfunc()
def c(self): # = param + 1 + otherfunc() + 3
return self.b + 3
This is just an illustration, real code makes more sense. but the expressions themselves are that simple.
Comments represent plugin output. I would like those values to be always visible as code hints, tooltips or whatever. and be updated as I type.
I don't want to evaluate the defs, because some of the values are not available before runtime. I want to get the expression itself from AST.
Obviously this is impossible to do in the general case. But I have a very specific use case in our code base
where very small python subset is used. And all the code follows the same pattern.
I already have a script that does this in python with ast module. I wonder if there is a way to do the same on the fly in Intellij.
Is there some way to achieve this? or something similar?
Is there a plugin that does something like that?
I doubt that there is. at least not exactly. So I want to try to implement it myself. (the use case is common and very annoying).
I skimmed through some of Intellij Platform Plugin SDK documentation. it's still not clear to me where to begin.
So what would be the easiest way to implement it from scratch or using another plugin as an example?
Is there an opensource plugin that does something similar that I can look at to figure out how to implement this myself?
My best guess is that I would need to implement:
create a call back that will be called every time def() is changed. (by implementing various extensions, no? which one?)
find this def in the file.
walk expression with PSI to extract the expression
create some GUI element to represent the def expression. (what are my options? is there some predefined elements that I can use?
ideally I would assign value to some existing GUI element)
assign value to the GUI element
but I don't know how to begin implementing any of the above. (I can probably figure out PSI part)
I searched for existing plugins, but couldn't find anything even remotely close. I skimmed the documentation, I did the tutorial, but I couldn't figure out which of the many extensions I need to use.
I considered using the debugger for that, but I don't see how debugger can help me here.
Any help (plugins, tutorials, extensions, plugins as an example, or details for implementation) would be greatly appreciated. thanks.
What you want to find is some extension point that will change the text user sees. I suggest you to look at the annotator class but maybe this is not the best extension point for you and you will need to find more suitable one (this is the most difficult part of creating plugins for JetBrain's IDEs). Full list of all available extension points you can find here.
After you find right extension point you need to implement it and change plugin.xml to let IDE know that some changes were made.
Some useful links:
Example plugins from developers
Official documentation
Quick course from JetBrain's developer (in Russian)
Example:
data class T(val flag: Boolean) {
constructor(n: Int) : this(run {
// Some computation here...
<Boolean result>
})
}
In this example, the custom constructor needs to run some computation in order to determine which value to pass to the primary constructor, but the compiler does not accept the run, citing Cannot access 'run' before superclass constructor has been called, which, if I understand correctly, means instead of interpreting it as the non-extension run (the variant with no object reference in https://kotlinlang.org/docs/reference/scope-functions.html#function-selection), it construes it as a call to this.run (the variant with an object reference in the above table) - which is invalid as the object has not completely instantiated yet.
What can I do in order to let the compiler know I mean the run function which is not an extension method and doesn't take a scope?
Clarification: I am interested in an answer to the question as asked, not in a workaround.
I can think of several workarounds - ways to rewrite this code in a way that works as intended without calling run: extracting the code to a function; rewriting it as a (possibly highly nested) let expression; removing the run and invoking the lambda (with () after it) instead (funnily enough, IntelliJ IDEA tags that as Redundant lambda creation and suggests to Inline the body, which reinstates the non-compiling run). But the question is not how to rewrite this without using run - it's how to make run work in this context.
A good answer should do one of the following things:
Explain how to instruct the compiler to call a function rather than an extension method when a name is overloaded, in general; or
Explain how to do that specifically for run; or
Explain that (and ideally also why) it is not possible to do (ideally with supporting references); or
Explain what I got wrong, in case I got something wrong and the whole question is irrelevant (e.g. if my analysis is incorrect, and the problem is something other than the compiler construing the call to run as this.run).
If someone has a neat workaround not mentioned above they're welcome to post it in a comment - not as an answer.
In case it matters: I'm using multi-platform Kotlin 1.4.20.
Kotlin favors the receiver overload if it is in scope. The solution is to use the fully qualified name of the non-receiver function:
kotlin.run { //...
The specification is explained here.
Another option when the overloads are not in the same package is to use import renaming, but that won't work in this case since both run functions are in the same package.
i use the Mathematical function "min" in my Kotlin code to declare a variable "toRemove"
val toRemove = min(preferredQuantity - taken, stock.quantity)
error message : Kotlin unresolved reference
1/ may i know how could i solve it?
2/ the function is within kotlin.math, why I cannot use it directly?
https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.math/
Thanks!
For completeness' sake: as pointed out by #Tenfour04 in the comments, make sure that kotlin.math.min is imported by checking that one of
import kotlin.math.min
import kotlin.math.*
is on top of the file. The kotlin.math.* variant will import everything from the kotlin.math package. See the Kotlin documentation page on imports.
Let's say you have a Fortran 90 module containing lots of variables, functions and subroutines. In your USE statement, which convention do you follow:
explicitly declare which variables/functions/subroutines you're using with the , only : syntax, such as USE [module_name], only : variable1, variable2, ...?
Insert a blanket USE [module_name]?
On the one hand, the only clause makes the code a bit more verbose. However, it forces you to repeat yourself in the code and if your module contains lots of variables/functions/subroutines, things begin to look unruly.
Here's an example:
module constants
implicit none
real, parameter :: PI=3.14
real, parameter :: E=2.71828183
integer, parameter :: answer=42
real, parameter :: earthRadiusMeters=6.38e6
end module constants
program test
! Option #1: blanket "use constants"
! use constants
! Option #2: Specify EACH variable you wish to use.
use constants, only : PI,E,answer,earthRadiusMeters
implicit none
write(6,*) "Hello world. Here are some constants:"
write(6,*) PI, &
E, &
answer, &
earthRadiusInMeters
end program test
Update
Hopefully someone says something like "Fortran? Just recode it in C#!" so I can down vote you.
Update
I like Tim Whitcomb's answer, which compares Fortran's USE modulename with Python's from modulename import *. A topic which has been on Stack Overflow before:
‘import module’ or ‘from module import’
In an answer, Mark Roddy mentioned:
don't use 'from module import *'. For
any reasonable large set of code, if
you 'import *' your will likely be
cementing it into the module, unable
to be removed. This is because it is
difficult to determine what items used
in the code are coming from 'module',
making it east to get to the point
where you think you don't use the
import anymore but its extremely
difficult to be sure.
What are good rules of thumb for python imports?
dbr's answer contains
don't do from x import * - it makes
your code very hard to understand, as
you cannot easily see where a method
came from (from x import *; from y
import *; my_func() - where is my_func
defined?)
So, I'm leaning towards a consensus of explicitly stating all the items I'm using in a module via
USE modulename, only : var1, var2, ...
And as Stefano Borini mentions,
[if] you have a module so large that you
feel compelled to add ONLY, it means
that your module is too big. Split it.
I used to just do use modulename - then, as my application grew, I found it more and more difficult to find the source to functions (without turning to grep) - some of the other code floating around the office still uses a one-subroutine-per-file, which has its own set of problems, but it makes it much easier to use a text editor to move through the code and quickly track down what you need.
After experiencing this, I've become a convert to using use...only whenever possible. I've also started picking up Python, and view it the same way as from modulename import *. There's a lot of great things that modules give you, but I prefer to keep my global namespace tightly controlled.
It's a matter of balance.
If you use only a few stuff from the module, it makes sense if you add ONLY, to clearly specify what you are using.
If you use a lot of stuff from the module, specifying ONLY will be followed by a lot of stuff, so it makes less sense. You are basically cherry-picking what you use, but the true fact is that you are dependent on that module as a whole.
However, in the end the best philosophy is this one: if you are concerned about namespace pollution, and you have a module so large that you feel compelled to add ONLY, it means that your module is too big. Split it.
Update: Fortran? just recode it in python ;)
Not exactly answering the question here, just throwing in another solution that I have found useful in some circumstances, if for whatever reason you don't want to split your module and start to get namespace clashes. You can use derived types to store several namespaces in one module.
If there is some logical grouping of the variables, you can create your own derived type for each group, store an instance of this type in the module and then you can import just the group that you happen to need.
Small example: We have a lot of data some of which is user input and some that is the result of miscellaneous initializations.
module basicdata
implicit none
! First the data types...
type input_data
integer :: a, b
end type input_data
type init_data
integer :: b, c
end type init_data
! ... then declare the data
type(input_data) :: input
type(init_data) :: init
end module basicdata
Now if a subroutine only uses data from init, you import just that:
subroutine doesstuff
use basicdata, only : init
...
q = init%b
end subroutine doesstuff
This is definitely not a universally applicable solution, you get some extra verbosity from the derived type syntax and then it will of course barely help if your module is not the basicdata sort above, but instead more of a allthestuffivebeenmeaningtosortoutvariety. Anyway, I have had some luck in getting code that fits easier into the brain this way.
The main advantage of USE, ONLY for me is that it avoids polluting my global namespace with stuff I don't need.
Agreed with most answers previously given, use ..., only: ... is the way to go, use types when it makes sense, apply python thinking as much as possible. Another suggestion is to use appropriate naming conventions in your imported module, along with private / public statements.
For instance, the netcdf library uses nf90_<some name>, which limits the namespace pollution on the importer side.
use netcdf ! imported names are prefixed with "nf90_"
nf90_open(...)
nf90_create(...)
nf90_get_var(...)
nf90_close(...)
similarly, the ncio wrapper to this library uses nc_<some name> (nc_read, nc_write...).
Importantly, with such designs where use: ..., only: ... is made less relevant, you'd better control the namespace of the imported module by setting appropriate private / public attributes in the header, so that a quick look at it will be sufficient for readers to assess which level of "pollution" they are facing. This is basically the same as use ..., only: ..., but on the imported module side - thus to be written only once, not at each import).
One more thing: as far as object-orientation and python are concerned, a difference in my view is that fortran does not really encourage type-bound procedures, in part because it is a relatively new standard (e.g. not compatible with a number of tools, and less rationally, it is just unusual) and because it breaks handy behavior such as procedure-free derived type copy (type(mytype) :: t1, t2 and t2 = t1). That means you often have to import the type and all would-be type-bound procedures, instead of just the class. This alone makes fortran code more verbose compared to python, and practical solutions like a prefix naming convention may come in handy.
IMO, the bottom line is: choose your coding style for people who will read it (this includes your later self), as taught by python. The best is the more verbose use ..., only: ... at each import, but in some cases a simple naming convention will do it (if you are disciplined enough...).
Yes, please use use module, only: .... For large code bases with multiple programmers, it makes the code easier to follow by everyone (or just use grep).
Please do not use include, use a smaller module for that instead. Include is a text insert of source code which is not checked by the compiler at the same level as use module, see: FORTRAN: Difference between INCLUDE and modules. Include generally makes it harder for both humans and computer to use the code which means it should not be used. Ex. from mpi-forum: "The use of the mpif.h include file is strongly discouraged and may be deprecated in a future version of MPI." (http://mpi-forum.org/docs/mpi-3.1/mpi31-report/node411.htm).
I know I'm a little late to the party, but if you're only after a set of constants and not necessarily computed values, you could do like C and create an include file:
inside a file,
e.g., constants.for
real, parameter :: pi = 3.14
real, parameter :: g = 6.67384e-11
...
program main
use module1, only : func1, subroutine1, func2
implicit none
include 'constants.for'
...
end program main
Edited to remove "real(4)" as some think it is bad practice.