Spock only allows static variables to be accessed from where block.
Is there any workaround using which Instance variables can be used inside the where block ?
You can annotate instance variables with #Shared, see Spock manual, chapter "Sharing of Objects between Iterations".
Attention: Shared instance variables will retain their values in between iterations and be shared between methods. If you do not want this, do not use the approach. But as I understand you, you initialise variable values using tables or so in the where block anyway, so it should be okay.
Related
I'm wondering
In grails's global variables - do we need to add mutex lock when access them ?
Example
Static variable in XXXService Class
Grails Application Context
I'm wondering In grails's global variables - do we need to add mutex
lock when access them ?
The JVM doesn't really have global variables. The closest thing to them are public static variables, which isn't really the same thing.
Whether or not you have to add a mutex depends on what you want to do with the variables. In general, the answer is "no", but that is in part because in general you wouldn't want to have mutable public static variables.
You only need to synchronize these objects if they need to be thread safe. Most things in the Grails Application Context do not need to be (such as just getting a singleton service).
So the answer to your question is not very clear-cut. Do it when you feel it is necessary to make sure that previous process has finished with the variable you care about.
I'm into Ruby on Rails programming for almost 5 weeks now.
I was wondering why people always use instance variables instead of local ones.
I always thought that you would use instance variables only for classes (so these instance variables are the attributes of the class).
But people also use them not only for being attributes of a class. And this is the part where I am getting confused.
For instance, take a look at these lines of codes:
class Foo
def print_a_hello
puts "Hello World"
end
end
#instance_variable = Foo.new
#instance_variable.print_a_hello
# => "Hello World"
locale_variable = Foo.new
locale_variable.print_a_hello
# => "Hello World"
So, who of you got a great explanation for me?
I was wondering why people always use instance variables instead of locale ones.
I'm not sure how you get that impression. I certainly don't "always" use instance variables. I use instance variables when I need an instance variable, and I use local variables, when I need a local variable, and most code I see does it the same way.
Usually, it doesn't even make sense to interchange them. They have completely different purpose: local variables have static lexical scope, instance variables have dynamic object scope. There's pretty much no way to interchange them, except for the very narrow case of a simple single-file procedural script, where the dynamic scope of the top-level main object and the lexical scope of the script body are identical.
I always thought that you would use instance variables only for classes (so these instance variables are the attributes of the class).
No. Instance variables are attributes of the instance (i.e. object), not the class, that's why they are called "instance variables", after all. Class variables are attributes of the class, but class variables are a different beast and only used in very specific circumstances. (Classes are objects (i.e. instances), too, so they can have instance variables as well; there's generally no need to use class variables, which have some weird and un-intuitive properties, unless you specifically need those weird and un-intuitive properties).
For instance, take a look on this short codelines:
class Foo
def print_a_hello
puts "Hello World"
end
end
#instance_variable = Foo.new
#instance_variable.print_a_hello
# => "Hello World"
locale_variable = Foo.new
locale_variable.print_a_hello
# => "Hello World"
This is the case I mentioned above: in this specific case (and only in this case), the dynamic scope of the top-level main object and the static lexical scope of the script body are identical, so it doesn't matter whether you use a local variable of the script body or an instance variable of the main object.
However, if we make just a tiny change to that, by adding a second script and requireing it from the first, that condition will no longer hold, because we now have two separate script bodies and thus two separate script scopes, but still only one top-level object.
The idiomatic way in your example would definitely be to use a local variable, and nobody I know would do otherwise.
Best use case for instance variables is in Controller's when you want to pass parameter to the view.
Then you use something like
class TestController < ActionController::Base
def show
#usable_in_view = Test.first
not_usable_in_view = Test.first
end
end
In your view you can now use #usable_in_view, but cant use variable not_usable_in_view. Most people always use instance variable in controllers even if they do not need them in view, because they do not understand why they need instance variable
Instance variables are used so that they can be accessed in the view page.
Local variables are not accessible in the view. It has become the habit even I sometimes write instance variables though it is not required in the view.:-)
People probably get in the [bad] habit of using instance variables everywhere since it's common in Rails to use them to get information from the controller to the view.
In my own Ruby code I use instance variables only when I need to, local variables otherwise. That's the proper way to use Ruby.
What is the difference between using a local variable, an instance variable, and one created with the 'let' method inside RSpec tests?
Using a let is the best choice if you need to reuse the variable, otherwise a local variable may make more sense. But you can decide for yourself given the differences:
Local variable
Only accessible from within one test, i.e. it cannot be reused.
Instance variable
Accessible from all tests within the example group. Assigned and evaluated on every test run in example group.
Let
Accessible from all tests within the example group. Lazily evaluated so it is only created (and the code to create it) when it is actually used in a test.
A let may still make sense instead of a local variable if the variable logically belongs to a context or describe block rather than an individual test—but that's preference based on test structure.
I think this this is a pretty stupid question but I just confused myself
I have several has_many defined. I can reference them in an instance method by saying self.------- If I try to reference via #------ I get nil. Is it just that because it's an ActiveRecord object that it's not available as an instance variable inside the class?
They are not set as instance variables, they are methods. Same as for your properties, you should always access them like this:
self.property
self.read_attribute(:property)
self.write_attribute(:property, value)
They could even be instance variables at the end, but this is an implementation detail and you should always call the code over the well known interface, which is the methods.
associations are methods not instance variables.
I need a global variable that I can call from the templates.
I edited app_globals.py in lib directory to declare PATH_TO_IMAGES like this
class Globals(object):
"""Container for objects available throughout the life of the application.
One instance of Globals is created during application initialization and
is available during requests via the 'app_globals' variable.
"""
PATH_TO_IMAGES = ""
def __init__(self):
"""Do nothing, by default."""
pass
Now I can call from any template the image path like this
<img src="${g.PATH_TO_IMAGES}/${p.image}" />
The image path is stored inside a settings table on the app's database, but I can't initialize it from Globals declaration, i get this error:
sqlalchemy.exc.UnboundExecutionError:
Could not locate a bind configured on
mapper
Mapper|Settings|settings,
SQL expression or this Session
My guess is that database binding happens after Globals is initialized. So my questions is, which is the best place to initialize a global variable in TurboGears 2 and which is the best practice to that.
Just use a cached property:
class Globals(object):
"""Container for objects available throughout the life of the application.
One instance of Globals is created during application initialization and
is available during requests via the 'app_globals' variable.
"""
#property
def PATH_TO_IMAGES(self):
try:
return self._path_to_images
except AttributeError:
self._path_to_images = db_session.query(XXX) # Fill in your query here
return self._path_to_images
PS : your question is a generic Python question really. I suggest you read the official Python docs before posting other similar questions.
You probably need to create your own database connection to get this data from the database.
In SQLAlchemy terms, you'll want to create your own engine, session, etc. Just make sure to clean up after you're done.
I would probably do this in app_cfg.py using on_startup to get it into the config, and then stick it in the Globals object later on if you still need to.
You may set PATH_TO_IMAGES to it's definite value once the models are initialized. The sooner being at the end of the 'init_model' function declared in model/init.py.