Myself being a C++/C# programmer I now have the misfortune of having to implement some changes into a bigger Actionscript/Air project written by somebody else some time ago.
Got the project to compile (well more or less) with "FlashDevelop" as an IDE. But For other reasons we want to use "IntelliJ" now.
Thing is that IntelliJ apparently does some more checking and now spits out dozens of errors like:
Error:(319, 0) [SomeSourceFile]: Implicit coercion of a value of type ByteArray to an unrelated type String.
On code like that:
public function send(ba:ByteArray):void{
mdm.COMPort.send(ba)
}
With the "mdm.COMPort.send" function expecting a string.
Yes, thats a type mismatch error! I fully agree!
But for some reason it worked with the old project. Apparently Actionscript was able to do some implicit type conversion/casting and did not check for type safety.
Question is now: How do I correct that? What was the implicit behaviour that actionscript applied in such cases?
mdm.COMPort.send(ba.toString())
mdm.COMPort.send(string(ba))
mdm.COMPort.send(ba as string)
mdm.COMPort.send(ba.ReadUTFBytes(ba.length))
Or other I do not know of?
I do have that problem now on many places with many types (not only "byte array" and "string"), so a general answer would be appreciated.
Related
Chisel throws an exception with an elaboration error message. The following is a result of my code as an example.
chisel3.core.Binding$ExpectedHardwareException: data to be connected 'chisel3.core.Bool#81' must be hardware, not a bare Chisel type. Perhaps you forgot to wrap it in Wire(_) or IO(_)?
This exception message is interesting because 81 behind chisel3.core.Bool# looks like ID, not hashcode.
Indeed, Data type extends HasId trait which has _id field, and
_id field seems to generate a unique ID for each components.
I've thought Data type overrides toString to make string that has type#ID, but it does not override. That is why $node in below code should not be able to use ID.
throw Binding.ExpectedHardwareException(s"$prefix'$node' must be hardware, " +
"not a bare Chisel type. Perhaps you forgot to wrap it in Wire(_) or IO(_)?")
Instead of toString, toNamed method exists in Data. However, this method seems to be called to generate a firrtl code, not to convert component into string.
Why can Data type show its ID?
If it is not ID, but exactly hashcode, this question is from my misunderstanding.
I think you should take a look at Chisel PR #985. It changes the way that Data's toString method is implemented. I'm not sure if it answers your question directly but it's possible this will make the meaning and location of the error clearer. If not you should comment on it.
Scala classes come with a default toString method that is of the form className#hashCode.
As you noted, the chisel3.core.Bool#81 sure looks like it's using the _id rather than the hashCode. That's because in the most recently published version of Chisel (3.1.6), the hashcode was the id! You can see this if you inspect the source files at the tag for that version: https://github.com/freechipsproject/chisel3/blob/dc4200f8b622e637ec170dc0728c7887a7dbc566/chiselFrontend/src/main/scala/chisel3/internal/Builder.scala#L81
This is no longer the case on master which probably the source of any confusion! As Chick noted, we have just changed the .toString method to be more informative than the default; expect more informative representations in 3.2.0!
I'm learning Dart and was reading the article Using Dart with JSON Web Services, which told me that I could get help with type checking when converting my objects to and from JSON. I used their code snippet but ended up with compiler warnings. I found another Stack Overflow question which discussed the same problem, and the answer was to use the #proxy annotation and implement noSuchMethod. Here's my attempt:
abstract class Language {
String language;
List targets;
Map website;
}
#proxy
class LanguageImpl extends JsonObject implements Language {
LanguageImpl();
factory LanguageImpl.fromJsonString(string) {
return new JsonObject.fromJsonString(string, new LanguageImpl());
}
noSuchMethod(i) => super.noSuchMethod(i);
}
I don't know if the noSuchMethod implementation is correct, and #proxy seems redundant now. Regardless, the code doesn't do what I want. If I run
var lang1 = new LanguageImpl.fromJsonString('{"language":"Dart"}');
print(JSON.encode(lang1));
print(lang1.language);
print(lang1.language + "!");
var lang2 = new LanguageImpl.fromJsonString('{"language":13.37000}');
print(JSON.encode(lang2));
print(lang2.language);
print(lang2.language + "!");
I get the output
{"language":"Dart"}
Dart
Dart!
{"language":13.37}
13.37
type 'String' is not a subtype of type 'num' of 'other'.
and then a stacktrace. Hence, although the readability is a little bit better (one of the goals of the article), the strong typing promised by the article doesn't work and the code might or might not crash, depending on the input.
What am I doing wrong?
The article mentions static types in one paragraph but JsonObject has nothing to do with static types.
What you get from JsonObject is that you don't need Map access syntax.
Instead of someMap['language'] = value; you can write someObj.language = value; and you get the fields in the autocomplete list, but Dart is not able to do any type checking neither when you assign a value to a field of the object (someObj.language = value;) nor when you use fromJsonString() (as mentioned because of noSuchMethod/#proxy).
I assume that you want an exception to be thrown on this line:
var lang2 = new LanguageImpl.fromJsonString('{"language":13.37000}');
because 13.37 is not a String. In order for JsonObject to do this it would need to use mirrors to determine the type of the field and manually do a type check. This is possible, but it would add to the dart2js output size.
So barring that, I think that throwing a type error when reading the field is reasonable, and you might have just found a bug-worthy issue here. Since noSuchMethod is being used to implement an abstract method, the runtime can actually do a type check on the arguments and return values. It appears from your example that it's not. Care to file a bug?
If this was addressed, then JsonObject could immediate read a field after setting it to cause a type check when decoding without mirrors, and it could do that check in an assert() so that it's only done in checked mode. I think that would be a nice solution.
I narrowed the causes of an AS3 compiler error 1119 down to code that looks similar to this:
var test_inst:Number = 2.953;
trace(test_inst);
trace(test_inst.constructor);
I get the error "1119: Access of possibly undefined property constructor through a reference with static type Number."
Now if I omit the variable's type, I don't get that error:
var test_inst = 2.953;
trace(test_inst);
trace(test_inst.constructor);
it produces the expected output:
2.953
[class Number]
So what's the deal? I like explicitly typing variables, so is there any way to solve this error other than not providing the variable's type?
ok, this is a little hard to explain ... first of all, here is how it works:
var test_inst:Number = 2.953;
trace(test_inst);
trace((test_inst as Object).constructor);
to my understanding, this comes from the fact, that the property constructor comes from the ECMAScript-nature of ActionScript 3. It is an ECMAScript property of Object instances and is inherited through prototypes. From the strictly typed world of ActionScript 3 (which also uses a different inheritance mechanism), this property is thus not available.
greetz
back2dos
http://www.kirupa.com/forum/showpost.php?p=1951137&postcount=214
that has all the info you need :)
basically, trace(test_inst["constructor"]) will work.
Object(someobject).constructor will achieve the same thing -- and you don't have to deal with compiler issues.
Object(someinst) === someclass works as well.
dh
Does anyone know the real difference between the two ways of type casting in Flex 3?
var myObject1:MyObject = variable as MyObject;
var myObject2:MyObject = MyObject(variable);
I prefer to use the second method because it will throw an Error when type cast fails, whereas the first method will just return null. But are there any other differences? Perhaps any advantages to using the first method?
The second type of casting has different behaviour for top level(http://livedocs.adobe.com/flex/2/langref/) types, e.g. Array(obj) does not cast in the straightforward way you describe; it creates a new Array if possible from obj, even if obj is an Array.
I'm sure the times this would cause unexpected behaviour would be rare but I always use "as" for this reason. It means if I do
int(str)
I know it's a cast in the "attempt to convert" sense of the word not in the "I promise it is" sense.
ref: got some confirmation on this from http://raghuonflex.wordpress.com/2007/07/27/casting-vs-the-as-operator/
The as method returns null if cast fails.
The () method throws and error if the cast fails.
If the value of variable is not compatible with MyObject, myObject1 will contain null and you will be surprised by a null pointer error (1009 : cannot access a property or method of a null object reference.) somewhere later in the program when you try to access it. Where as if you are casting using the MyObject(variable) syntax, you will get a type coercion error (1034 : Type Coercion failed: cannot convert _ to _) at the same line itself - which is more helpful than getting a 1009 somewhere later and wondering what went wrong.
I think I read somewhere on this site that as is slighty faster than (), but I can't find the question again.
Beside that this question have been asked many times, you will find an more in-depth answer here.
I recently discovered the very useful [] tag when searching on StackOverflow, it allows to only search in questions tagged with the specified tag(s). So you could do a search like [actionscript-3] as vs cast. There are more search tips here: https://stackoverflow.com/search.
And no; the irony in that I can not find the question about performance and write about how to search is not lost on me ;)
I think as returns back the base class and not null when the casting fails and () throws an error.
I have a simple grammar, and have produced a pair of c# classes using antlr 2.7.7. When the parser finds an error with a token, it throws an exception; I want to find out how many characters into a parsed stream the token came. How do I do that?
It's been a long time ago since I played with ANTLR, but if I remember well, to do what you want, I had to subclass the parser to keep a counter of characters that was incremented each time a new token was found (with the token length of course).
You ought to read chapter 10 ("Error Reporting and Recovery") from Terrence Parr's book "The Definitive ANTLR Reference".
Not knowing what target language you're using, it'll be hard to tell you exactly what to do. But I'll assume you're using the Java target, and you can correct me if I'm wrong.
When an ANTLR recognizer fails to match an input string, it throws a very specific exception, based on the failure context. (There are nine different kinds of exceptions, RecognitionException is the root type, and it has eight subclasses of its own: MismatchedTokenException, MismatchedTreeNodeException, NoViableAltException, EarlyExitException, FailedPredicateException, MismatchedRangeException, MismatchedSetException, MismatchedNotSetException).
The root exception type (RecognitionException) has a few handy public fields that you might want to take a look at (specifically: "index", "line" and "charPositionInLine"). The "index" field tells you the exact character position where the error was found. The "line" and "charPositionInLine" fields are pretty self-explanatory. Here's the JavaDoc:
http://www.antlr.org/api/Java/classorg_1_1antlr_1_1runtime_1_1_recognition_exception.html