Google turns up nothing on this error: Combination of indirect name lookup and call not supported
My code:
use Vimwiki::File::TextProcessingClasses;
unit class Vimwiki::File::ContentStr;
has Str $.content;
method process($class) {
$!content = Vimwiki::File::TextProcessingClasses::($class).process($!content);
}
The compiler is not happy with this and complains with aforesaid error. If I hard-code in in the $class name, everything works.
Anyway around this?
OK, solution is to precede the package name with ::, like so:
$!content = ::Vimwiki::File::TextProcessingClasses::($class).process($!content);
Documentation is here: https://docs.raku.org/language/packages#Looking_up_names
Though I don't know precisely why what I was doing originally behaves differently.
Related
Example:
data class T(val flag: Boolean) {
constructor(n: Int) : this(run {
// Some computation here...
<Boolean result>
})
}
In this example, the custom constructor needs to run some computation in order to determine which value to pass to the primary constructor, but the compiler does not accept the run, citing Cannot access 'run' before superclass constructor has been called, which, if I understand correctly, means instead of interpreting it as the non-extension run (the variant with no object reference in https://kotlinlang.org/docs/reference/scope-functions.html#function-selection), it construes it as a call to this.run (the variant with an object reference in the above table) - which is invalid as the object has not completely instantiated yet.
What can I do in order to let the compiler know I mean the run function which is not an extension method and doesn't take a scope?
Clarification: I am interested in an answer to the question as asked, not in a workaround.
I can think of several workarounds - ways to rewrite this code in a way that works as intended without calling run: extracting the code to a function; rewriting it as a (possibly highly nested) let expression; removing the run and invoking the lambda (with () after it) instead (funnily enough, IntelliJ IDEA tags that as Redundant lambda creation and suggests to Inline the body, which reinstates the non-compiling run). But the question is not how to rewrite this without using run - it's how to make run work in this context.
A good answer should do one of the following things:
Explain how to instruct the compiler to call a function rather than an extension method when a name is overloaded, in general; or
Explain how to do that specifically for run; or
Explain that (and ideally also why) it is not possible to do (ideally with supporting references); or
Explain what I got wrong, in case I got something wrong and the whole question is irrelevant (e.g. if my analysis is incorrect, and the problem is something other than the compiler construing the call to run as this.run).
If someone has a neat workaround not mentioned above they're welcome to post it in a comment - not as an answer.
In case it matters: I'm using multi-platform Kotlin 1.4.20.
Kotlin favors the receiver overload if it is in scope. The solution is to use the fully qualified name of the non-receiver function:
kotlin.run { //...
The specification is explained here.
Another option when the overloads are not in the same package is to use import renaming, but that won't work in this case since both run functions are in the same package.
I have an error that used to look like this in Objective-C
NSString * const JKConfigurationErrorDomain;
typedef NS_ENUM(NSInteger, JKConfigurationCode) {
JKConfigurationCodeUnknown,
JKConfigurationCodeSomethingBad,
JKConfigurationCodeParsing,
};
Now, this is ugly to use in Swift. But since Swift 4, we can use NSErrorDomain and NS_ERROR_ENUM to make the imported error much nicer in Swift:
NSErrorDomain const JKConfigurationErrorDomain;
typedef NS_ERROR_ENUM(JKConfigurationErrorDomain, JKConfigurationCode) {
JKConfigurationCodeUnknown,
JKConfigurationErrorSomethingBad,
JKConfigurationErrorParsing,
};
This means I can now do stuff in Swift like this:
if let myError = error as? JKConfigurationError, myError.code = .somethingBad {
// handle it
}
instead of having to cast error to NSError, then check its .domain then look at the .code which is an integer, etc.
So far, so good. But my library is called JKConfiguration and there is already a JKConfiguration object (the center piece of the library) in there and as soon as I start using JKConfiguration anywhere in the library code I get an error:
'JKConfiguration' is ambiguous for type lookup in this context
I don't get it, why? What does NSErrorDomain or NS_ERROR_ENUM do such that the type lookup becomes ambiguous and how can I fix it?
What I tried already:
use NS_SWIFT_NAME on the NS_ERROR_ENUM typedef and rename it to something else. Looking at the generated Swift header, the rename works, but doesn't solve the issue
Change the name of the error domain (and thus of the generated error type in Swift). Seems to work according to the generated Swift header, but the issue still persists. Why is that?
The issue is not, as I initially thought, in the name of the error domain. Nor is it a problem with the library name. It’s a problem of the error enum‘s name, in the example above: JKConfigurationCode.
What the Compiler does for the enum cases of an NS_ERROR_ENUM is two-fold:
use the name of the enum and remove that prefix from all enum cases before importing them to swift
create an enum with the given name to hold those cases. If the given name ends with Code remove that suffix.
So that last part is the issue. It means that NS_ERROR_ENUM(AnyDomainName, JKConfigurationCode) generates an enum in Swift to hold the error codes with the name JKConfiguration (without the Code) prefix. But that type already exists in my example, which leads to the ambiguity.
So the solution is to change
NS_ERROR_ENUM(JKConfigurationErrorDomain, JKConfigurationCode)
to
NS_ERROR_ENUM(JKConfigurationErrorDomain, JKConfigurationSomethingCode)
Or similar.
Don’t forget to update all the prefixes of your enum cases though, as it seems the compiler won’t find them if the prefixes don’t match the enum name.
Why doesn’t NS_SWIFT_NAME work to rename the enum?
Best I can tell, NS_SWIFT_NAME causes the type to be renamed but not the cases. This leads to an empty type (Swift chooses a struct in that case) being generated for the error code as Swift doesn’t seem to find the cases. And the original container for the enum cases still has the offending name.
I have 2 classes lets call them A and B, I also have a function that converts an instance of A to an instance of B.
My code that is causing issues is basically:
fun fromAtoB(a: A) = B (fb1 = a.fa1, fb2 = a.fa2, fb3 = a.fa3)
val listOfA: List<A> = ...
val listOfB: listOfA.map { fromAtoB(it) }
This won't build due to the line:
fromAtoB(it)
With the error:
Due to the error Type checking has run into a recursive problem. Easiest workaround: specify types of your declarations explicitly
I Have no clue what I can do to fix this, Google had provided no results that seem to apply to my issue...
Thanks in advance for any help!
EDIT:
Here are the actual source files:
TenantEntity.kt - https://pastebin.com/mdSWiA1Y (Line 51 of this file
is the issue)
TenantDto.kt - https://pastebin.com/83UP9Cwe
ReceiptEntity.kt - https://pastebin.com/BjP2ikg9
ReceiptDto.kt - https://pastebin.com/Kpt9dSAp
This type of problem means that the compiler can't infer what the type of listOfB should be, because you have a recursive call somewhere in its definition. That's curious as I can't see any in your example code, but maybe you left out the offending code inadvertently. Anyways, this problem is usually resolved by doing what the error message suggests, manually specifying the return type like so:
val listOfB: List<B> = listOfA.map { fromAtoB(it) }
Edit:
After trying the real code, I just went after a hunch and changed line 45 in TenantEntity.kt from this:
fun fromDto(dto: TenantDto) = TenantEntity (
to this:
fun fromDto(dto: TenantDto): TenantEntity = TenantEntity (
and the error was gone. I'm not really sure why, but it should compile now.
Second edit:
Upon further inspection, you're going to run into a StackOverflowException with this code, which is ultimately why the compiler couldn't resolve the type. When you call TenantEntity.fromDto(...), that will call ReceiptEntity.fromDto(...), which will in turn call TenantEntity.fromDto(...), and back again, into eternity (or the stack limit). That's not going to work, you'll need to fix your logic there.
The title pretty much sums it up, but here's the long version anyway.
After posting a small snippet of perl code, I was told to avoid indirect object notation, "as it has several side effects". The comment referenced this particular line:
my $some_object = new Some::Module(FIELD => 'value');
As this is how I've always done it, in an effort to get with the times I therefore ask:
What's so bad about it? (specifically)
What are the potential (presumably negative) side effects?
How should that line be rewritten?
I was about to ask the commenter, but to me this is worthy of its own post.
The main problem is that it's ambiguous. Does
my $some_object = new Some::Module(FIELD => 'value');
mean to call the new method in the Some::Module package, or does it mean to call the new function in the current package with the result of calling the Module function in the Some package with the given parameters?
i.e, it could be parsed as:
# method call
my $some_object = Some::Module->new(FIELD => 'value');
# or function call
my $some_object = new(Some::Module(FIELD => 'value'));
The alternative is to use the explicit method call notation Some::Module->new(...).
Normally, the parser guesses correctly, but the best practice is to avoid the ambiguity.
What's so bad about it?
The problems with Indirect Method Notation are avoidable, but it's far easier to tell people to avoid Indirect Method Notation.
The main problem it's very easy to call the wrong function by accident. Take the following code, for example:
package Widget;
sub new { ... }
sub foo { ... }
sub bar { ... }
sub method {
...;
my $o = new SubWidget;
...;
}
1;
In that code, new SubWidget is expected to mean
SubWidget->new()
Instead, it actually means
new("SubWidget")
That said, using strict will catch most of these instances of this error. Were use strict; to be added to the above snippet, the following error would be produced:
Bareword "SubWidget" not allowed while "strict subs" in use at Widget.pm line 11.
That said, there are cases where using strict would not catch the error. They primarily involve the use of parens around the arguments of the method call (e.g. new SubWidget($x)).
So that means
Using Indirect Object Notation without parens can result in odd error messages.
Using Indirect Object Notation with parens can result in the wrong code being called.
The former is bearable, and the latter is avoidable. But rather than telling people "avoid using parens around the arguments of method calls using Indirect Method Notation", we simply tell people "avoid using Indirect Method Notation". It's just too fragile.
There's another issue. It's not just using Indirect Object Notation that's a problem, it's supporting it in Perl. The existence of the feature causes multiple problems. Primarily,
It causes some syntax errors to result in very odd/misleading error messages because the code appeared to be using ION when it wasn't.
It prevents useful features from being implemented since they clash with valid ION syntax.
On the plus side, using no indirect; helps the first problem.
How should that line be rewritten?
The correct way to write the method call is the following:
my $some_object = Some::Module->new(FIELD => 'value');
That said, even this syntax is ambiguous. It will first check if a function named Some::Module exists. But that's so very unlikely that very few people protect themselves from such problems. If you wanted to protect yourself, you could use the following:
my $some_object = Some::Module::->new(FIELD => 'value');
As to how to avoid it: There's a CPAN module that forbids the notation, acting like a pragma module:
no indirect;
http://metacpan.org/pod/indirect
The commenter just wanted to see Some::Module->new(FIELD => 'value'); as the constructor.
Perl can use indirect object syntax for other bare words that look like they might be methods, but nowadays the perlobj documentation suggests not to use it.
The general problem with it is that code written this way is ambiguous and exercises Perl's parser to test the namespace to e.g. check when you write method Namespace whether Namespace::method exists.
I've made a program that uses reflection to add Traits dynamically, and solves conflicts automatically in one predeterminated way.
It uses aliases. It's working (I think), but I have only a problem when finally adding the trait.
My program generates all the aliases for each conflicting method, and add them with the trait to the class. The problem is that I'm not able to generate the selector correctly, its generating a string instead.
For example:
I need this
TCircle # {#circleHash -> #hash}
but I'm generating this
TCircle # {'#circleHash' -> #hash}
you can see the quotes in #circleHash.
Because is a meta-program, it generates also dynamically the selector.
How I can get it without the quotes and with the #?
I need to able to do something like this
"have the selector name in string"
obj := 'SelectorDinamicallyGenerated'.
^(#obj)
and get #SelectorDinamicallyGenerated, and not '#SelectorDinamicallyGenerated'.
How can I do this?
I've tried doing like that (#obj) but it is not working (getting #obj)
I've found it.
It's
obj asSymbol
Good you found it yourself. Maybe it is just irritating that in smalltalk a symbol is a selector. It is just not the case that there is a selector class and you could do "aString asSelector". So
'foo' asSymbol => #foo
will do. If you need to generate a setter you can do
'foo' asSymbol asMutator => #foo: