I have a class file myClass.m in a package folder +myPack that's on the path. A simple example of the class file is:
classdef myClass
properties
prop
end
methods
function obj = myClass(x)
obj.prop = x;
end
end
end
Now if I directly call the method and access the property using the full package name, i.e.:
x = myPack.myClass(2).prop;
returns x = 2 correctly. Now, if I try the same by importing this class (and not use the package name):
import myPack.myClass
y = myClass(2).prop
it gives me the following error:
Static method or constructor invocations cannot be indexed.
Do not follow the call to the static method or constructor with
any additional indexing or dot references.
Why does this work in the first case and not the second? As far as I understood, importing a class mainly allowed one to use the class name without the long package name (among other considerations). What is the difference in these two that causes this error and how can I work around it?
Here is some more weird for you: the behavior is different if you are running in the command window, from a script, or from a function!
1) command prompt (1st: ok, 2nd: error)
This is what you've already shown
>> x = myPack.myClass(2).prop
x =
2
>> import myPack.myClass; y = myClass(2).prop
Static method or constructor invocations cannot be indexed.
Do not follow the call to the static method or constructor with
any additional indexing or dot references.
2) Script (1st: error, 2nd: error)
testMyClassScript.m
x = myPack.myClass(2).prop
import myPack.myClass; y = myClass(2).prop
and
>> testMyClassScript
Static method or constructor invocations cannot be indexed.
Do not follow the call to the static method or constructor with
any additional indexing or dot references.
Error in testMyClassScript (line 1)
x = myPack.myClass(2).prop
(the second line would also throw the same error)
3) Function (1st: ok, 2nd: ok)
testMyClassFunction.m
function testMyClassFunction()
x = myPack.myClass(2).prop
import myPack.myClass; y = myClass(2).prop
end
and
>> testMyClassFunction
x =
2
y =
2
I would definitely call that a bug :) The expected behavior is to give an error in all cases.
Related
I'm trying to use a function that is inside a file (module 1) in another file (module) 2. But it gives me an error "ERROR: UndefVarError: t1 not defined". I have tried to export the function in module 1 but it also doesn't work. I'm new to Julia and I do not know very well how to handle modules.
Here is the code that I'm having problems.
First File: t1.jl
module A
function soma(a::Int64, b::Int64)
return a + b
end
end
Second File: t2.jl
module B
include("t1.jl")
using .t1
function main()
s = soma(2, 3)
println(s)
end
main()
end
Changing t2.jl to:
module B
include("t1.jl")
using .A
function main()
s = A.soma(2, 3)
println(s)
end
main()
end
prints out 5 as expected.
include is basically as if you'd copy-pasted the code from the included file into the current file - so, once you've included t1.jl into module B, the fact that the file is called t1.jl has no relevance. It's module A that's in the current scope, and A is the namespace that contains the soma function we need. Hence, using .A is what's needed to make soma available within B.
I'm trying to implement a simple function in pure lodash way.
function forward(i) => {
return (j) => {
return String.fromCharCode(i + j)
}
}
So that I can do _.range(26).map(forward(65)). Take me some time to make this work:
function a = _.wrap(String.fromCharCode, (fn, a, b) => fn(a + b))
function b = _.ary(a, 2)
function forward = _.curry(b)
Now my question is is there an easier way to do this? and how do I use sum to construct (fn, a, b) => fn(a + b)?
One last thing is I couldn't find wrap function file in Lodash repo.
The function _.curry(...) is kind of strange when it comes to calling functions with various parameters. Let me guide you with an example below.
The ary-function (_.ary(..., 2)) takes any function and ensures its never called with more than a specific amount of arguments (in this case two). Less arguments than specified, will just end up calling the underlying function with less arguments. A definition of this function could look like this:
function ary() {
const args = arguments;
// implementation
}
There is no way to tell how many arguments the function is expecting, as you would with a function with actual parameters (function(a, b) { }). If you would define const forward1 = _.curry(_.ary(target, 2)), and call it with forward1(42)(2), the curry function would just pass down the first argument to ary as it thinks its done.
We can get around this by using an overload of curry that specifies how many parameters the underlying function is expecting (const forward2 = _.curry(target, 2)). Only in the case where forward2 is called in a curry-style (not sure what its even called) with two parameters, it passes it down to target. A call with one argument will just return a new function, waiting for it to be called with the second argument. Now we can get rid of the ary-call, as it serves us no purpose anymore.
As for chaining actions, there's a helper for that. For example: c(b(a(...) can be rewritten to _.flow([a, b, c]). Lodash also provides a function for a + b, which is _.add().
Together your problem can be rewritten to:
const forward = _.curry(_.flow([_.add, String.fromCharCode]), 2);
or more verbose:
const methods = _.flow([
_.add,
String.fromCharCode
]);
const forward = _.curry(methods, 2);
Note that the 2 corresponds to the amount of parameters the _.add method expects.
I'm trying to write a program in D that involves a Server class which creates new Client objects when new clients join. I want to pass the server object to the clients when they created, however when later I try to access the Server object from the client, my program stops with error code -11. I've googled it but found nothing.
I've successfully recreated this behavior in the following snippet:
import std.stdio;
class Server
{
public:
int n;
Client foo() //Foo creates a new client and passes this to it
{return new Client(this);}
}
class Client
{
public:
this(Server sv) //Constructor takes Server object
{sv=sv;}
Server sv;
void bar() //Function bar tries to access the server's n
{writeln(sv.n);}
}
void main()
{
Server s = new Server; //Create a new server object
Client c = s.foo(); //Then ask for a client
//c.sv=s; //!!!If I leave this line in the source then it works!!!
sv.n=5; //Set it to a random value
c.bar(); //Should print 5, but instead crashes w/ error -11
}
If I uncomment the c.sv=s line, then is magically works, which I don't understand.
So why is that if I set sv in the constructor then it crashes, but if I set it later then it works?
EDIT:
Adding writeln(sv) to the bar function prints null, so it can cause the crash. But why is it null?
{sv=sv;}
This line is the mistake. It sets the local sv, not the class instance. Try this.sv = sv; instead to set the instance member to the local.
edit: so since you never set the instance variable, it remains uninitialized - defaulting to null.
I'm trying to add automatic support for property declarations, so that a class gets getters and setters generated automatically for them. I use the middleclass library as a base for classes. I've defined a root class that handles property creation. However, in tests, only an immediate subclass of the root class works properly. Others give me stack overflow error deep inside the middleclass code ([string "local middleclass = {..."]:82: stack overflow).
My code is:
local CBaseObject=class('CObjectBase');
function CBaseObject:initialize()
self._init=true;
end;
function CBaseObject:finalize()
self._init=false;
end;
function CBaseObject:_getter_setter(v)
return v;
end;
function CBaseObject:_gen_prop_cache()
rawset(self,'_properties',rawget(self,'_properties') or {});
end;
function CBaseObject:__index(k)
print('GET',k);
self:_gen_prop_cache();
local prop=self._properties[k];
if prop~=nil
then
local getter=self[prop[2] or '_getter_setter'];
return getter(self,prop[1]);
else return nil;end;
end;
function CBaseObject:__newindex(k,v)
print('ME',self.class.name);
print('SET',k,v);
self:_gen_prop_cache();
local prop=self._properties[k];
if prop==nil and self._init or prop
then
if prop==nil then prop={};self._properties[k]=prop;end;
local vv=prop[1];
if type(v)=='table' and #v<4
then
for i=1,3 do prop[i]=v[i];end;
else
prop[1]=v;
end;
local setter=self[prop[3] or '_getter_setter'];
prop[1]=setter(self,prop[1],vv);
else
rawset(self,k,v);
end;
end;
Test classes:
local cls=CBaseObject:subclass('test');
function cls:initialize()
self.class.super.initialize(self);
self.health={1000,'_gethealth','_sethealth'};
self.ammo=100;
self:finalize();
end;
function cls:_sethealth(value,old)
print('WRITE:',value,old);
if value<0 then return old;else return value;end;
end;
function cls:_gethealth(value)
print('READ:',value);
return value/1000;
end;
local cls2=cls:subclass('test2');
function cls2:initialize()
self.class.super.initialize(self);
self.ammo=200;
self:finalize();
end;
function cls2:_sethealth(value,old)
print('WRITE_OVERRIDEN:',value,old);
return value;
end;
local obj=cls2(); --change this to cls() for working example.
obj.health=100;
obj.health=-100;
print(obj.health,obj._properties.health[1]);
print(obj.ammo,obj._properties.ammo[1]);
I used https://repl.it/languages/lua to run my code. So, the questions is, is what I do even the right approach? Is it possible to add property support in an easier way compatible with the used library? Or should I use another, and what then?
EDIT: after experimenting I found out that the construct self.class.parent.<method>(<...>) is to blame for the error. I replaced all such occurrences by actual parent classes. That was the only problem, it seems, after that the code started to work error-free so far.
Enrique García Cota (middleclass creator) has enlightened me with what I think is a nice way to implement getters/setters on middleclass.
He suggested to create and use a mixin.
I've done some minor changes while testing/using this mixin recipe. Currently the one I'm using looks like this:
-- properties.lua
local Properties = {}
function Properties:__index(k)
local getter = self.class.__instanceDict["get_" .. k]
if getter ~= nil then
return getter(self)
end
end
function Properties:__newindex(k, v)
local setter = self["set_" .. k]
if setter ~= nil then
setter(self, v)
else
rawset(self, k, v)
end
end
return Properties
You would have to create function get_* and function set_* for your properties (or modify the string pattern above as you wish).
Example:
local class = require('middleclass')
local Properties = require('properties')
local Rect = class('Rect'):include(Properties)
function Rect:initialize(x, y, w, h)
self.x = x
self.y = y
self.w = w
self.h = h
end
function Rect:get_right()
return self.x + self.w
end
function Rect:set_right(right)
self.x = self.x + right - self.right
end
r = Rect:new(10,10, 100, 100)
print(r.right) -- 110
print(r:get_right()) -- 110
r.right = 200
print(r.right) -- 200
print(r.x) -- 100
This way you can use this mixin in whatever classes you want to have properties and simply create the get_* and set_* functions on it.
He also said, however:
I am not a huge fan of getters/setters in Lua. In other languages, I can accept them; for example in ruby, they are integrated in the language's message-passing mechanism.
But in Lua they are extra syntactic sugar, and risk making things more "magical" (unexpected to someone unfamiliar with the code).
Performance note: It's worth mentioning, however, that using __index functions, like the example does, should impact heavily on your code's performance (if compared to __index tables).
Personally, after some time using getters and setters (due to my Python bias), I've decided to write things explicitly and no longer rely on them.
It depends, of course, if performance is critical or not for your code.
Here is my scenario.
I have the following line of code in my program:
JCL_History.Enqueue(JCL_History(I))
This JCL_History object is basically a Generic.List encapsulated in a wrapper and has the following method:
Public Sub Enqueue(ByRef value As String)
If Members.Contains(value) Then
Me.RemoveAt(Members.IndexOf(value))
ElseIf _Count = _MaxCount Then
Me.RemoveAt(_Count - 1)
End If
Me.Insert(0, value)
End Sub
So you see that the first line of code that invokes Enqueue should "shuffle" items around.
Also, the wrapper class of which JCL_History is a type has the following default property:
Default Public Property Item(ByVal Index As Integer) As String 'Implements Generic.IList(Of String).Item
Get
If Index < _MaxCount Then
Return Members(Index)
Else
Throw New IndexOutOfRangeException("Bug encountered while accessing job command file history, please send an error report.")
End If
End Get
Set(ByVal value As String)
If Index < _MaxCount Then
If Index = _Count Then _Count = _Count + 1
Members(Index) = value
Else
Throw New IndexOutOfRangeException("Bug encountered while accessing job command file history, please send an error report.")
End If
End Set
End Property
In my testing I have 2 items in this JCL_History list. When I call that first line of code I posted (the one that invokes Enqueue) with I = 1 I expect the first item to be shuffled to the bottom and the second item to be shuffled to the top.
After the thread returns from Enqueue I notice that this is exactly what happens to my list, HOWEVER if I hit the "step_in" button after the execution of Enqueue I go into the Default Property's set method where Index = 1 and value = and it screws everything up, because the item that got shuffled to the end (index 1) gets overwritten by the item value shuffled to the top.
So basically the set method on the default property is getting called at what I think to be a completely ridiculous time. What gives? By the way I'm running VS2005 on XP.
Do you have a watch and/or are you executing a quick watch via a mouse-over that would read a property that might invoke the Set? If your debugging environment evaluates something that changes data, you can get weird behavior like what you're describing.
Whether or not the case above is true, if multiple threads can write to Members, consider using ReaderWriterLockSlim.
No answer. Never fixed this, just worked around it.