I have a python class that is a type. So the super is not object but type.
Befoer pydev version 10.1.1 the first parameter had to be 'cls'. Now errors are reporting that it should be 'self'. Pylint thinks 'cls' is fine.
Any suggestion how to inform pydev its a metaclass, not a normal class?
code:
class MyMeta(type):
#property
def edit_es(cls):
return 'EDIT'
Related
I'm getting a warning for every Ecmascript 6 class that inherits from another class when compiling with Closure Compiler:
I've dumbed things down as much as possible and still get the warning:
/src/main/js/com/tm/dev/Dog.js: WARNING - Bad type annotation. Unknown type module$$src$main$js$com$tm$dev$Animal.default
The compiled code does run correctly. (I've tried a number of annotations which only made things worse.) Anyone know what's expected here?
Animal.js:
export default class{
constructor(){
this.legs = [];
}
addLeg(legId){
this.legs.push( legId );
}
}
Dog.js:
import Animal from './Animal';
export default class extends Animal {
constructor(){
super();
[1,2,3,4].forEach(leg=>this.addLeg(leg));
console.log( 'Legs: ' + this.legs.toString() );
}
}
A hint is in the warning message, though it would obviously be confusing if you're not familiar with Closure Compiler's annotation inspection.
The Closure Compiler can use data type information about JavaScript variables to provide enhanced optimization and warnings. JavaScript, however, has no way to declare types.
Because JavaScript has no syntax for declaring the type of a variable, you must use comments in the code to specify the data type.
(The following is untested.)
Closure Compiler is reporting that in Dog.js it does not recognise the "type" Animal. This is because you are exporting an unnamed class expression: export default class.
So you could give your class a name (export default class Animal) and Closure Compiler may recognise the token Animal when it is consumed in Dog.js.
And you can also give your class a JSDoc that marks it as a #constructor:
/**
* Animal.
* #constructor
*/
export default class Animal {}
In my project I have Swift extensions over Objective C enums, which worked brilliantly in Xcode 7.2.
But with Xcode 7.3 it fails with "undeclared type" in the Swift file where I extend the Obj C enum.
I've built a sample project and it compiles and works well, but I can't make the existing project accept the extension over the Obj C enum.
UPDATE:
After reinstalling Xcode 7.2 I can confirm that the project compiles and builds successfully.
After it worked in Xcode 7.2, I tried launching this project again in Xcode 7.3 and again the same issue -> the Swift extension over Obj C enums can't be build.
After cleaning and deleting the derived data in Xcode 7.3 I receive also the -Swift.h header missing error because the Swift classes haven't been compiled so a header wasn't created yet.
Code explanation:
My Obj C enum inside "FriendRequestResult.h":
typedef NS_ENUM(NSInteger, FriendStatus)
{
FriendStatusRequestedByUser = 1,
FriendStatusRequestedByOtherUser,
FriendStatusFriends,
FriendStatusBlocked,
FriendStatusNone,
FriendStatusError,
};
Now, as expected in my AppName-Bridging-Header.h I have:
#import "FriendRequestResult.h"
Then, I have the swift extension over the FriendStatus which builds in Xcode 7.2, but fails with "use of undeclared type" in Xcode 7.3:
extension FriendStatus
{
init(stringValue : String?)
{
if let stringValue = stringValue
{
switch stringValue
{
case "REQUESTED_BY_USER": self = .RequestedByUser
case "REQUESTED_BY_OTHER": self = .RequestedByOtherUser
case "FRIENDS": self = .Friends
case "BLOCKED": self = .Blocked
default: self = .None
}
}
else
{
self = .None
}
}
}
Actually this extension over the enum has also some other helper functions, but that should not change the problem in any way.
Of course if the extension of the enum gives the undeclared type, then using this type fails everywhere in the Swift code with the same "undeclared things". Basically the enum is not visible at all for the Swift part of the project, even though the import is made in the bridging header.
This question was substantially edited from its first version.
Solution 1:
Moved the enum in a seaparate header file.
My enum declaration was in the same header as a class header and specifically it was between the #interface and #end of that class.
In Xcode 7.2 it was creating no issues and the parsing of the header was successful, while in Xcode 7.3 they probably optimised something and changed the way it's parsed, so it was seeing my class, but not the enum inside it [maybe it declares it as private if it's inside a class declaration]
Solution 2: Moved the enum declaration outside the #interface #end scope.
To answer your question: "Can I somehow force Xcode to generate the Swift header first? Or can I force Xcode to believe that my enums exist somewhere and that it should validate my extensions?"
I found 2 ways to order file compilation.
Using a target and making it a dependency of your project.
Opening the project.pbxproj file and editing the list manually.
Depending on the level of risk and complexity you are ready to tackle, pick one or the other.
I just tried extending an ENUM and things are working fine here. One issue I had in the past was understanding the name stripping convention between Obj-C and Swift but this doesn't look like the issue you are running into.
The other issue I encounter invariably is maintaining the ##$% Bridging-Header.h file all the time. Are you positive this is up-to-date?
I can do this and I don't have any issues:
class MyClass:
def introduce(self):
print("Hello, I am %s, and my name is " %(self))
MyClass.introduce(0)
MyClass().introduce()
I'm using Visual Studio and Python 3.4.1. I don't understand why this doesn't throw an error since I'm basically setting the value of this. Is this a feature and I just shouldn't be doing this? Should I be checking if self is actually an instance of MyClass?
In Python 3 when you do MyClass.introduce() introduce is not linked to any object. It's considered as a (standalone) function like any other function you would declare by itself. The fact that it is declared within a class is not relevant here. introduce is therefore called like any function: a function with one parameter.
When you do MyClass().introduce() (notice the first set of parentheses) introduce is considered as a method belonging to an object which is an instance of class MyClass hence the regular OO behavior of adding automatically the self parameter.
Note that this is different for python 2. In python 2 there is a check to verify that when called, the effective argument passed for the self parameter is indeed an object of the correct type, i.e. an instance of MyClass. If you try MyClass.introduce(0) in Python 2 you'll get: unbound method introduce() must be called with MyClass instance as first argument (got int instance instead). This check doesn't exist in Python 3 anymore because the notion of unbound method no longer exist.
I'm attempting to un-Spring IoC several Java classes and load them directly in some Scala code. Naturally I'm finding that there are name space conflicts between a package like
com.a.x.SomeClass
and
com.a.y.x.SomeClass
I've tried using the import name space resolvers like
import com.a.y.x.{ SomeClass => YYYSomeClass }
import com.a.x{ SomeClass => XXXSomeClass }
That cleans up the imports, but referring to those classes later in the classes show the error as hovers in the Typesafe ScalaIDE, and after clean compilations.
When I compile from the gradle scala plugin, or via the Typesafe ScalaIDE with scala 2.10.2 or 2.10.3, I get the following type of un-useful error messages:
class SomeClass in package x cannot be accessed in com.a.y.x
The problem occurs if I try to use a class from com.a.y.x that doesn't have a name space conflict. If I try some of the scalac flags, I've also been able to get a Warning out that's slightly different ( during the typer stage ):
class SomeClass in package x cannot be accessed in y.this.x
I'd really like to know if there's a way to expand the first package reference. I'm having trouble setting up an Eclipse project to debug the scalac compiler and I haven't found a scalac flag that adds useful information to the error.
The error occurs when I either try to ctx.getBean("someClass").asInstanceOf[XXXSomeClass] or new XXXSomeClass.
The this reference from the warning makes me think there's some object confusion going on. I don't think it's classpath issue in the larger project I'm working on because removing one jar removes the ability to resolve imports, however I can't reproduce it with simple example classes in a separate project.
A little more information on the java classes - the different, conflicting java packages are in separate jars that were compiled by a 1.6 flavor of Java. They are top level, public classes although two are singletons with private constructors and corresponding public static getInstance() methods.
It really is an access error. I think this is just a poor error message. The java was compiled separately and accessed from jar files. I hadn't paid enough attention to the package private nature of the classes I wanted to instantiate( I had seen "public" in front of some of them and not carefully checked all of them ). The name space collisions were a red-herring in this case and actually don't affect the output of the error message.
In some cases, there are public interfaces I can use instead with a little bit of Spring-glue to instantiate the objects and load them into the Scala class.
The scalac error message would have been more helpful if it had the form:
class SomeClass in package com.a.y.x cannot be accessed in totally.unrelated
where the first package reference is the Java class's package and the trailing package is the package of the Scala class trying to instantiate the Java class.
To recap - the Java class was like:
package com.a.y.x.SomeClass
class SomeClass extends SomeOtherClass implements SomeInterface
and needs to be like:
package com.a.y.x.SomeClass
public class SomeClass extends SomeOtherClass implements SomeInterface
to not get these access errors.
Since I have more control of the Scala here, on a whim I tried changing the package of a Scala class from totally.unrelated to com.a.x.y which then compiles cleanly. As you might guess, that merely defers the error to a run time error -> java.lang.IllegalAccessError. However, the IllegalAccessError from the Java has the description/package order that I think should happen in the compilation error from scalac:
...java.lang.IllegalAccessError: tried to access class com.a.y.x.SomeClass from class s.Trouble$delayedInit$body
I was facing the same error as asked in this question
I overcome with this error by solution of declaring class ahead of time in my .h file with the class parameter
I am having FFTBufferManager.h and FFTBufferManager.cpp file and using it in HomeView.h and HomeView.mm file
class FFTBufferManager,CAStreamBasicDescription,DCRejectionFilter;
But now I am having error as
#include "FFTBufferManager.h"
#include "aurio_helper.h"
#include "CAStreamBasicDescription.h"
class CAStreamBasicDescription,FFTBufferManager; //here it shows this error
EXpected Unqualified-id befor ',' token
#interface HomeView
{
FFTBufferManager* fftBufferManager;
//it shows erros
EXpected Unqualified-id befor ',' token
ISO c++ forbids declaration of FFTBufferManager with no type
}
#property FFTBufferManager* fftBufferManager;
//shows error
'FFTBufferManager' is not a type
I'm gathering you're using both C++ and Objective-C.
I'd suggest renaming all your .cpp and .m files in which Objective-C and C++ code are meeting to use the extension .mm - this tells the compiler to use "Objective-C++" rules, and will stop a lot of compiler troubles.
Also, it seems CAStreamBasicDescritpion is a C++ class - you'll have to forward-declare it with class CAStreamBasicDescritpion;, not #class CAStreamBasicDescritpion; (note, no "at" sign) - the second form is only for forward-declaring Objective-C classes. This I suspect is the root cause of the particular error you have observed.
EDIT in response to comment: I'm not sure about your first new issue - that should work fine so long as both FFTBufferManager and CAStreamBasicDescription are C++ classes. As to your second one, depending on where exactly that line of code is (CAStreamBasicDescription thruFormat;) you may need to include the header rather than just the forward-declare: you're declaring an instance of CAStreamBasicDescription here, and the compiler needs to know its structure to do so.
You can't declare more than one class at a time.
Change your declarations to
class CAStreamBasicDescription;
class FFTBufferManager;
The compiler is looking for an unqualified-id because it believes that you're declaring a variable of type CAStreamBasicDescription, so it expects a variable name where you gave it a comma.
Looks like you are trying to create a class that already exists in one of the Cocoa frameworks.