What function can I use to check if a association is already loaded?
It would be nice to check if a association is loaded instead of trying to use it and getting Ecto.Association.NotLoaded error.
You can use assoc_loaded?
Reference:
https://hexdocs.pm/ecto/Ecto.html#assoc_loaded?/1
Not sure if there's a built-in function to check for this, but you could write your own like this:
defmodule PreloadCheck do
def is_preloaded(model, assoc) do
case Map.get(model, assoc) do
%Ecto.Association.NotLoaded{} -> false
_ -> true
end
end
end
Here assoc would be the atom representing your association name.
Using pattern matching in case allows you to check if your association is loaded or if it's still returning a Ecto.Association.NotLoaded struct.
Related
I'm trying to check if a certain node type has a property
without actually needing to make an instance of it
like this:
print("z_index" in Position2D);
Classes in ClassDB
If we are talking about a build-in class (not a custom class that you created, but one that is part of Godot), you can use ClassDB to get the property:
var properties := ClassDB.class_get_property_list("Position2D")
Classes from Godot Scripts
If the class is not in ClassDB (which is the case custom classes), but you have the script, you can use the script to get the property list:
var properties := preload("res://custom_class.gd").get_script_property_list()
If you don't have the script, perhaps you can find it. This code uses the hidden project setting "_global_script_classes" to find the path of the script for a class given the name_of_class you are looking for, and loads it:
if ProjectSettings.has_setting("_global_script_classes"):
for x in ProjectSettings.get_setting("_global_script_classes"):
if x.class == name_of_class:
return load(x.path)
Addendum: This is no longer available in Godot 4.
Other classes
However, the above approach will not work for every type of script. In those cases, I'm afraid the best way is to instance it. You can still get the properties from the instance and cache them (perhaps put them in a dictionary) so that you are not creating a new instance every time you need to query:
var properties := (CustomClass.new()).get_property_list()
Query the properties
Regardless of how you got the property list, you can query them the same way. For example this code looks for a property with name "z_index" and gets its type:
var found := false
var type := TYPE_NIL
for property in properties:
if property.name == "z_index":
found = true
type = property.type
break
prints(found, type)
The type is a Variant.Type constant.
Theraot's answer is correct, since it provides a way to check attributes without creating an instance of a node/gdscript.
You can also check the properties of an existing instance of a node/scene by doing this:
if "attribute_name" in thing:
pass # do stuff here
Practical example; During a signal triggered by two Area2Ds colliding, check if one node's attribute item_type is set:
func _on_area_2d_area_entered(area):
if "item_type" in area:
print(area["item_type"])
Booleans are being prefixed with the can, shall, will, is etc
in order to indicate its type (boolean) and I guess even more important:
it's meaning.
But when it comes to commands (void methods) I find it not as simple.
I saw commands like enable(bool) parameter which sets a value true or false.
But I don't think that a method called enable(...) should ever do a "disable".
I'd prefer making an addition method which disables() without parameter or a method called Set...(bool param)
But which convention describes how this parameter should be called?
The approach prefixing it with Is is a bit confusing in my opinion as Is
always indicates a state of something but not but if want to set a boolean value via a command explicitly I don't think it makes sense to prefix the parameter.
How would you name such a function(s parameter)?
void SetHasSpecialSetting(bool flag) => this.HasSpecialSetting=flag;
Update:
As I pointed out, prefixing booleans imply that their type is bool obviously.
More over it makes it more readable in situation where you need this bool as condition.
But for commands that only set a bool property to a given value it is not needed to know the meaning of the property nor that it is of type bool because that i clear.
First, I agree with the commenters: if there is a naming rule in the project, use it.
While your implementation is also good, I do not prefer that approach, using generic function + parameter(s). When I have to implement something similar, I prefer (in pseudocode):
set ( parameter ) => parameter = true
reset ( parameter ) => parameter = false
or:
setParameter () => parameter = true
resetParameter () => parameter = false
For me, this is easier to read. I moved the true / false information into the name of the function. Other people use clear instead of reset. That is also very good, but again, that is not my preference.
Bottom line:
Firstly, study the project (or talk to the people) and find the currently used naming rules. Follow them if they exist.
Secondly, make your decision based on the facts.
I have passed a block to the ensurable method and defined acceptable property values as well as the methods of the provider that are to be called. I understand that present and absent property depend on the result of the exist? method and depending on it they will be called/not called. However, I have a case where I also want other actions (my_action1, my_action2) to also depend on exists? result, is it possible to achieve that?
ensurable do
newvalue(:present) do
provider.create
end
newvalue(:absent) do
provider.destroy
end
newvalue(:my_action1) do
provider.my_action1
end
newvalue(:my_action2) do
provider.my_action2
end
end
I write module which will define new types. Inside newproperty definition I want to use custom function (also provided in this module) which will munge passed value:
Function
#lib/puppet/parser/functions/my_custom_function.rb
module Puppet::Parser::Functions
newfunction(:my_custom_function, :type => :rvalue) do |args|
...
end
end
Type
#lib/puppet/type/new_type.rb
Puppet::Type.newtype(:new_type) do
newparam(:name) do
munge do |value|
my_custom_function(value)
end
end
end
but I get undefined local variable or method when try use function in type like above.
I also don't have access to stdlib functions inside custom type, but these functions are available in manifest file.
Does someone can provide example how to execute custom function inside type definition especially in munge block?
Custom functions are parser functions, for use in your manifests only.
The type code is used by the agent only, which will not load parser functions while initializing resources.
You will have to duplicate your munging code. If this is not feasible, you may have to implement it in a custom Ruby library, and use that from both within your custom function and your type. The library will need to be installed on both masters and agents in this case.
You need to extract the code from your custom function into a separate location and then call that shared code from both your custom function and from your type/provider. You do not need to pull the code into a separate gem to do this, it is fairly easy to keep the code local to your module.
Put your own Ruby classes in the directory lib/puppet/util/ of your module. You should then be able to require 'puppet/util/my_class' from both your custom function and your type/provider. You can see an example of how I've done this in my module jboss-puppet_admin.
I'm trying to return a type from a fortran function. This is the code.
module somemodule
implicit none
! define a simple type
type sometype
integer :: someint
end type sometype
! define an interface
interface
! define a function that returns the previously defined type
type(sometype) function somefunction()
end function somefunction
end interface
contains
end module somemodule
In gfortran (4.4 & 4.5) I get the following error:
Error: The type for function 'somefunction' at (1) is not accessible
I compiled the file as:
gfortran -c ./test.F90
I tried to make the type explicitly public but that didn't help. I was planning to use a c version of the somefunction, that is why I put it in the interface section.
Why is the type not accessible?
Adding import inside the function definition fixes this. Due to what many consider a mistake in the design of the language, definitions aren't inherited inside of an interface. The "import" overrides this to achieve the sensible behavior.
interface
! define a function that returns the previously defined type
type(sometype) function somefunction()
import
end function somefunction
end interface
The answer to the question why it is not accessible is that the standard committee designed it like that. The interface has a separate scope from the enclosing module, so you have to explicitly import names from it. Obviously(?) you can't use the module inside itself, so the import statement is needed.