When I compile my source , I get the following error: type error in argument(s) of functor `source/1'
The compiler correctly determines the types of the arguments, but keeps trying to use a field from a different record.
Whats wrong?
The problem is a missing ':- include_module' for the data type being used. The compiler knows what the type is, even if you don't have the module specified.
I found the answer by using the more verbose syntax:
my_functor(Val1, Val2, Val3) = Variable
Where the compiler clearly told me that my_functor wasn't defined. In this particular instance, the "source" field was named in two different structures in two different modules, one of which was imported, making the error message somewhat more confusing.
Related
Is there any way autoload Hack type aliases? I've placed them in separate files on PSR-4-compliant paths, and although I understand they are Hack-only and aren't formally mentioned in the PSR-0 or PSR-4, I figured one of the following would happen:
HHVM would expand type aliases to their base types, or
spl_autoload would treat the type as a class, function or interface name and execute the script, resolving the alias.
However, neither happen. At runtime, the methods call fail due to incompatibility with the type hints, i.e.:
Catchable fatal error: Argument passed to {method_name} must be an instance of {type_alias}, {concrete_type} given.
Edit: I should mention that I am specifically using Composer. I'm unsure if this is Composer-specific or not.
Yes, you can autoload types in HHVM. You need to be using a class-map approach and the HH\autoload_set_paths function.
There is the hhvm-autoload package which adds support for generating the necessary map into composer.
I don't believe this is possible. PHP doesn't register type hints for autoloading. And it doesn't need to, because the only way to fulfill the type hint is to pass that class or subclasses, whose construction would've triggered the autoloader call. It is impossible then for a type hint to be unknown to the interpreter at the time it checks against it.
This is only a problem in Hack because type aliases introduce this possibility. To stay consistent with PHP, I expect the only viable solution of the two mentioned would be for HHVM to expand type aliases while compiling the bytecode.
I have just started working on my first golang project and really like the idea of returning custom error types from functions and using type assertion in the calling code, to check for specific errors. I find this solution cleaner than always comparing error messages.
My only question is: where do you best put these custom error types?
Say a number of custom error types is only used (returned) by one utility function, should they go in the same package as the function? Should I group them somehow? Or maybe there's a better way of doing this kind of thing..
"Same package" would be my initial thought. There may be cases where having them in a different package would make sense, but that would only be if they're legitimately "the same error" from functions in multiple packages, with none of those packages being the logical "most owner".
This is my code :
int x=65;
char ch{x};
And this is the warning when compiled with `-std=C++11 flag:
Narrowed conversion from "int to char"
But I think there should be an error as x is not a constant and we are initializing ch with a non-constant value. What actually happens?
You're right that the standard treats this as an error, and allows implementations to flat out reject this code.
However, implementations are almost never required to reject code that does not conform to the standard. They have to diagnose the problem, but if they attach the label "warning" to it and continue to accept the code, there is no problem.
In this case, C++11 made perfectly well-formed C++03 code into an error (not entirely your code, but char ch[] = {x}; used to be valid), so compilers have a good reason to treat it as only a warning: they want to accept as much formerly valid code as reasonable, or users might have a good reason to switch to another compiler.
clang will give you an error:
main.cpp:23:9: error: non-constant-expression cannot be narrowed from type 'int' to 'char' in initializer list [-Wc++11-narrowing]
gcc as far as I remember decided to issue warning as there is too many source code that would be broken by such decision.
when you initialize variable using uniform initialization then narrowing conversions are forbidden.
I would like to define my Error Codes in a package models.
error.go
package models
const{
EOK = iota
EFAILED
}
How can I use them in another package without referring to them as models.EOK. I would like to use directly as EOK, since these codes would be common across all packages.
Is it the right way to do it? Any better alternatives?
To answer you core question
You can use the dot import syntax to import the exported symbols from another package directly into your package's namespace (godoc):
import . "models"
This way you could directly refer to the EOK constant without prefixing it with models.
However I'd strongly advice against doing so, as it generates rather unreadable code. see below
General/style advice
Don't use unprefixed export path like models. This is considered bad style as it will easily globber. Even for small projects, that are used only internally, use something like myname/models. see goblog
Regarding your question about error generation, there are functions for generating error values, e.g. errors.New (godoc) and fmt.Errorf (godoc).
For a general introduction on go and error handling see goblog
W.r.t. the initial question, use a compact package name, for example err.
Choosing an approach to propagating errors, and generating error messages depends on the scale and complexity of the application. The error style you show, using an int, and then a function to decode it, is quite C-ish.
That style was partly caused by:
the lack of multiple value returns (unlike Go),
the need to use a simple type (to be easily propagated), and
that gets translated to text with a function (unlike Go's error interface), so that the local language strings can be changed.
For small apps with simple errors strings. I put the packages' error strings at the head of a package file, and just return them, maybe using errors.New(...), or fmt.Errorf if the string needs to be completed using some data.
That 'int' style of error reporting doesn't offer something as flexible as Go's error interface. The error interface lets us build information-rich error structures, to return useful information, and not just an int value or string.
An implication is different packages can yield different real-types which implement the Error interface. We don't need to agree a single error real-type across an entire set of packages. So error is an interface which can be easily propagated, like an int, yet, the real-type of error can be much richer than an int. Error generation (implementing Error) can be as centralised or distributed as we need, unlike strerror()-style functions which can be awkward to extend.
This question already has answers here:
golang type assertion using reflect.Typeof()
(6 answers)
Closed 7 years ago.
My Problem is as follows:
I have a slice of reflect.Value, that was returned from a MethodByName("foo").Call().
now i want to cast the contained values to their types, which i dont know statically, but in form of relflect.Type
Basically what i want to do is:
values[0].Interface().(mytype)
but with reflection
values[0].Interface().(reflect.TypeOf(responseObject))
This gives me the compilation error:
reflect.TypeOf(responseObject) is not a type
Is there a way to do this in go?
Thanks and regards
BillDoor
If you have code using the normal type assertion syntax like:
x := v.(mytype)
Then the compiler knows that the variable x is of type mytype, and generates code accordingly. If the language let you use an expression in place of the type, then the compiler would have no way of knowing what type x is, and consequently no way to generate code that uses that variable.
If you only know the type of value at runtime, then you will need to stick with the reflect.Value API. You can determine the value's type using its Type method, and there are methods that will let you access struct fields, indexes in slices or arrays, etc.
You will only be able to move back to regular syntax when you have a type you know about at compile time.
What is a cast (type assertion)? It has two effects:
At compile time, the compile-time of the whole type assertion expression is the type casted to.
At runtime, a check is made on the actual runtime type of the value, and if it is not the type casted to, it will generate a runtime error.
Obviously, #1 doesn't make sense for a type that is not known at compile-time, because how can the compile-time type of something depend on something not known at compile time?
You can still do manually do #2 for a type that is not known at compile time. Just get the runtime type of the value using reflect.TypeOf() and compare it against the runtime.Type you have.