Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

non-null object-typed args should be checked for shared functions #2410

Open
gavinking opened this issue Oct 31, 2015 · 7 comments
Open

non-null object-typed args should be checked for shared functions #2410

gavinking opened this issue Oct 31, 2015 · 7 comments

Comments

@gavinking
Copy link
Member

Something I sorta vaguely thought we already did, but don't do is properly validate arguments that might be coming from Java code. Given this:

shared void xxx(Object oo) {
    print(oo.string);
}

We should generate:

public static void xxx(final .java.lang.Object oo) {
    com.redhat.ceylon.compiler.java.Util.checkNull(oo);
    ceylon.language.print_.print(ceylon.language.String.instance(oo.toString()));
}
@lucaswerkmeister
Copy link
Member

I want to disagree, sounds too expensive for too little gain. Not our fault if shitty Java authors don’t correctly call beautiful Ceylon code ;)

We should probably implement this, bench it, and then decide if it’s too expensive.

@gavinking
Copy link
Member Author

Well if(x==null) is not very expensive. And we don't have to do it for primitives, or for nullable types.

@lucaswerkmeister
Copy link
Member

But I’m pretty sure non-null non-primitive parameter types are the most common case, and the way you wrote it in the issue description, we would also (completely unnecessarily) suffer this cost for every Ceylon→Ceylon call.

@jvasileff
Copy link
Member

Sure, the cost would be small, but I agree with @lucaswerkmeister, validating every argument is too much. And who knows, there could be weird hotspot issues, at least with the method call as written.

I'm also not sure that handwritten Java code calling Ceylon code is a common pattern. If true, this would mostly be for frameworks. Which you've already said should be using direct field manipulation 😜.

@lucaswerkmeister
Copy link
Member

An alternative form to generate, without Ceylon→Ceylon cost, would be:

public static void xxx(final .java.lang.Object oo) {
    .com.redhat.ceylon.compiler.java.Util.checkNull(oo);
    .com.example.xxx$canonical$(oo);
}
public static void xxx$canonical$(final .java.lang.Object oo) {
    .ceylon.language.print_.print(.ceylon.language.String.instance(oo.toString()));
}

where all Ceylon code would directly call the $canonical$ version, but OTOH this means a lot of duplicate methods.

@gavinking
Copy link
Member Author

I'm also not sure that handwritten Java code calling Ceylon code is a common pattern.

Well I just observed an NPE in the IDE Ceylon code.

@jvasileff
Copy link
Member

How about adding @NotNull (or whatever) annotations to generated code? Do these things work in practice?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants