Suppose I have two methods in my class, methodA and methodB. In methodA, I create an object, S, of class X and then I want to pass this object to methodB. THen, when I am writing methodB, I want the type of X to be known so that when I use it, typing in my IDE, I can just type "X." and see a list of methods and instance variables for S. Is this impossible in python?
def methodA(self):
S = X()
self.methodB(S)
def methodB(self, S):
"S."....#here I want to see all the methods of variable S.
This isn't really a question about Python. Rather, it's a question about IDEs.
I haven't seen an IDE that would be able to do what you're asking. Also, given the dynamic nature of Python, it would be very hard to implement such code completion except for some special cases.
If your IDE supports a rope plugin you can have partial autocomplete support.
The editor I'm using (SublimeText) supports a rope plugin, then I can type:
class Class(object):
def __init__(self):
self.var1 = "one"
self.var2 = "two"
self.var3 = "three"
def method_1(self):
pass
def method_2(self):
self.var1 = "one**" # Autocomplete works here, no need of workarounds
def test_method(obj1_, obj2_):
# To make autocompletion works here, I start suffixing the parameters with _
if False: # Then I define each parameter statically
obj1 = Class()
obj2 = Class()
# Autocomplete now works!
obj1.method_1()
print obj2.var1
# Remember to rename obj1_ to obj1, ...
###
Maybe rope supports a kind of annotations to make the above workaround unnecessary, but I cannot find good examples of it.
Related
According to the GTK API reference, the "license-type" property of GtkAboutDialog is only present in GTK >= 3.0. For compatibility, my code currently checks the GTK version before setting the "license-type" property:
-- This is Lua code binding to GTK via lgi
local dialog = Gtk.AboutDialog {
title = "About Me",
-- ...,
}
if Gtk.check_version(3,0,0) == nil then
dialog.license_type = Gtk.License.MIT_X11
end
Instead of doing this, is there a way to directly ask GTK if a widget supports a certain property? I think the code would be more self-documenting and less bug prone if I could write something that looks like
if supports_property(dialog, "license-type") then
dialog.license_type = Gtk.License.MIT_X11
end
Since this question is really about the GTK API, I'm OK with answers in any programming language. Although the examples are in Lua, I assume a similar problem should show up in other dynamic-language bindings or even in C, assuming that there is a way to set properties by name without going through the set_license_type accessor function.
You don't need to use the _property field like you are doing in your currently accepted answer since lgi finds all names in the type categories tables directly. Additionally, it is also possible to get type of an instance using _type accessor. So I'd recommend following solution:
if dialog._type.license_type then
dialog.license_type = Gtk.License.MIT_X11
end
You can use the g_object_class_find_property() function to see if a property exists.
Note that this function takes a GObjectClass, not the GObject instance. All GObject classes come in these class-instance pairs, with the class structure used for shared things like vtable methods. To get the GObjectClass associated with an object instance, in C, you can use the G_OBJECT_GET_CLASS() macro. (If you want to do this in Lua, and if Lua can't call C macros like that, you'll have to trace the definition of G_OBJECT_GET_CLASS().)
In lgi, a class's properties are present in its _property field:
if Gtk.AboutDialog._property.license_type then
dialog.license_type = Gtk.License.MIT_X11
end
If for some reasons you need to know if a property is present without instantiating it, you can go with #andlabs idea in this way:
local lgi = require'lgi'
local Gtk = lgi.require'Gtk'
local class = Gtk.AboutDialogClass()
-- Prints yes
if class:find_property('license') then print('yes') end
-- Does not print anything
if class:find_property('unknown') then print('yes') end
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.
I'm using tolua++ to automatically expose C++ types to Lua. It seems that when I expose some type, e.g.
struct TestComponent
{
float foo;
string bar;
}
What tolua does (at least this is what it seems like to me) is add a new metatable to the lua environment (in this case it would just be called TestComponent) with some regular metamethods such as __add, __lt, as well as __index, __newindex, etc. It also has some custom functions (called .set and .get) which seem to be used when you get or set certain members of the struct/class. The type of TestComponent here seems to be just "table".
However, what it seems to lack, for simple structure definitions like above, are functions/methods to create a new instance of the type TestComponent, e.g.
a = TestComponent:new()
The question, then, is, how do I create a new instance of this type and assign it to a variable? For example, to hand it to a function that expects an argument of type TestComponent.
It's been a few years since I used tolua++, but based on the docs it appears that if your struct had a constructor, then you could create the object with a = TestComponent() or a = TestComponent:new() (both should work, unless you have an older version of tolua++). Without a constructor in the C++ struct, the docs don't say, but based on what you state, it seems like the TestComponent becomes a regular table object with the given fields and associated values, in which case it does not make sense to have a constructor (the table is the object, you can't create multiple instances of it).
So if you can edit the C++ header of the struct to add a constructor to it, it'll probably work. If you can't do that, then you could define a constructor yourself (note: not tested):
function TestComponent:new()
local obj = {}
for k,v in pairs(self) do
obj[k] = v
setmetatable(obj, self)
return obj
end
You might have to filter the keys so you only get values (not functions, for example), or replace the loop with explicit assignments such as:
function TestComponent:new()
local obj = {}
obj.foo = self.foo
obj.bar = self.bar
setmetatable(obj, self)
return obj
end
I'm trying to implement a object notation in Lua scripts.
Here is what I succeeded to do with the C API:
I created a new global table "Test" as a class and added a field "new" in it, pointing to a function written in C
i.e I can do this in lua code: "local obj = Test.new()" (it calls the function "new")
The "new" C function creates and returns a new table, and registers functions in it as fields (e.g "add", "count"...)
i.e I can do this: "obj:add("mike")" and "obj:count()" (obj is passed as first arguments with the ":" notation)
2 questions:
1) Everything works as expected, but the thing I'm wondering is: What is the advantage of using metatables in my case?
I see everywhere that metatables can help me to achieve what I tried to do, but I don't understand where they would be useful?
Adding fields to tables as methods isn't correct?
How could metatables help me (If added as my tables metatables)?
2) In fact I'm trying to reproduce the behaviour of C++ in Lua here.
For example, when I write this in C++: "Test *obj = new Test();"
I expect C++ and the constructor of Test to return me a pointer of an instance of Test.
This is exactly what I'm trying Lua to do for me.
The thing is that I use a table in this case, as the return of "new", but not a pointer so I can call methods on it later with Lua (using its fields), like a standard C++ object (with the operator ->).
To be able to retreive the actual pointer of my class in the C fonctions, I added a field "ptr" (light uservalue) to the table returned by "new". Without it, I would have been able to manipulate only the Lua table in my C function, nothing more (so no more method calls on the real pointer).
My second question is, Is it the right way to do it?
Do you have better idea on how to be able to manipulate my pointer everywhere without this "ptr" field?
Thank you,
Nicolas.
The main reason is that you get the __index metamethod.
Without it, every instance of a object has to have all the functions associated with it: which can make tables why large; and use a lot of memory.
local methods = {
foo = function() return "foo" end ;
bar = function() return "bar" end ;
bob = function() return "bob" end ;
hen = function() return "hen" end ;
}
So you have either
function new_no_mt ( )
local t = {}
for k , v in pairs ( methods ) do t [ k ] = v end
return t
end
vs
local mt = { __index = methods ; }
function new_mt ( )
return setmetatable ( { } , mt )
end
There are other benefits too;
defining operators;
easy type comparison via comparing metatables.
Changing method in metatable changes it for all objects, but changing it on one object only changes it for that object.
Otherwise, what you are trying to do sounds like the perfect situation for userdata.
userdata can only be indexed when you have an __index metatmethod (theres no table to put methods in)
What is the advantage of using metatables in my case?
Here's one.
Test.new = function() end
I just destroyed your ability to create new Test objects globally. If you had protected Test with a metatable, I would have had to really work to be able to do that.
Here's another:
local myTest = Test()
You can't do that without a metatable (overload the __call metamethod). And it looks much more natural for Lua syntax than calling Test.new.
And another:
local testAdd = Test() + Test()
Operator overloading. You can't do that without metatables.
Also:
This is exactly what I'm trying Lua to do for me.
Here's a tip: don't.
Different languages are different for a reason. You should do things in Lua the Lua way, not the C++ way. I can understand wanting to provide certain C++ mechanisms (like overloading and so forth), but you shouldn't use new just because that's what C++ uses.
Also, there are plenty of libraries that do this work for you. SWIG and Luabind are two big ones.
Say, If i have two or more files using the middleclass extension more or less like this. I omitted some of the obvious middleclass implementation code.
File A:
function Battlefield:initialize()
self.varA
self.varB
end
function Battlefield:attack()
--I want to use self.varA here
end
File B
BattlefieldInstance = Battlefield:new()
function doStuff()
BattlefieldInstance:attack()
end
I know this structure more or less works because i already use it plenty on my project, but my problem is that i want to use these self variables. Normally a self instance is passed between functions inside the same file to do this, but when i do it from another file i obviously can't pass self, because it would be another self, and i need the self from the file where the function is located. Sorry if my question is a bit confusing. I'll try and clarify any questions there are.
I have no idea what middleclass is, but I think you're confusing yourself. The way self works in Lua is a function that looks like function Battlefield:attack() is absolutely the same thing as function Battlefield.attack(self). In other words, self is just an implicit first parameter to the function. And a method call instance:attack() is exactly equivalent to instance.attack(instance) (though it won't evaluate instance twice if you use an expression there).
In other words, BattlefieldInstance:attack() should do exactly what you want.
'self' is a keyword that means 'the current object'. So in the case of Battlefield functions, 'self.varA' inside the function is the same variable as 'Battlefield.varA' outside the function.
Middle Class was a lib that I first saw developed for Love2D; I assuming its the same one that corona is using? (I've used Corona a fair bit... but not Middle Class's OOP system)
either way you can also try using meta tables directly, as so:
---FILE A---
Battlefield= {}
Battlefield.__index = Battlefield
function Battlefield:new()
return setmetatable({var1 = 'somedata', var2 = 'somemodata', var3 = 'lotsodata'}, Battlefield)
end
function Battlefield:attack()
print(self.var1)
end
---FILE B---
BattlefieldInstance = Battlefield:new( )
function doStuff()
BattlefieldInstance:attack()
end
and that'll print out self.var1 (somedata).
Hope this helps!