-
Notifications
You must be signed in to change notification settings - Fork 34
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
partial private default constructor for Java framework interop (JPA...) #1405
Comments
FTR : ceylon/ceylon-compiler#2250 removed a part of the pain with |
uhm...on second thought, something still bothers me, but I don't know how this can be solved. class Foo{
abstract new(){}
shared new init(String bar, String baz){} // yuck !
} in a perfect world, I'd like to be able to use the classes of my entities as perfectly normal classes, but the partial constructor trick leaks as this unnecessary init constructor. class Foo(String bar, String baz){
abstract new(){}
} but this obviously breaks the golden rule of constructors VS class parameters.... |
AFAICT this could only be allowed on classes with a nonempty parameter list, otherwise both constructors would have the same Java signature. |
yes indeed, @lucaswerkmeister but anyway if I have a class with a an empty parameter list JPA is perfectly happy with the generated public constructor and I don't need the abstract one. |
What about an annotation in |
So the big question is: do we ever need this default constructor to actually do anything? If it's always empty, then I suppose an annotation in But if there are some cases where we do need to do something in this constructor then that solution isn't quite good enough. Thoughts? |
No, not there: the compiler doesn't know about |
I'm not sure I understand that, assuming you mean the Ceylon |
Well, no, not really.
|
Well, to solve the particular case of JPA, we could just always generate a |
Well the only problem with that is bloat. |
Well how much bloat is one empty constructor with no parameters? |
In every class in a module though. Also doesn't it need to be |
Well we need to measure what is the impact of that in terms of a %.
Probably. |
OK, let me try |
Cool, thanks. On Thu, Oct 1, 2015 at 11:52 AM, Tom Bentley notifications@github.com
Gavin King |
Problem: What about a Ceylon class with a Java superclass without a nullary constructor? We can't generate a nullary constructor in that case. |
0% for the SDK, to 2 d.p. at least. |
Sure, there are some cases where you shouldn't generate this:
Perhaps there are some others, I'm not sure. |
@tombentley aah, but what happens with |
Or you assign Java default values? |
I'm assigning default values. The suppression of javac errors is something which we're only doing in very limited circumstances. |
Cool, well that's fine. |
My concern about the corner cases where we don't generate such a constructor is that it might be non-obvious to the user why it suddenly doesn't work, and since it's an implicit thing there's nowhere that we can put an error to say "this isn't going to work". It just mysteriously won't work at runtime. |
Oh, what about generic classes, btw: We need reified type parameters, but JPA wan't supply them. So I guess we shouldn't generate ctors in that case either. |
@tombentley I don't see how they're corner cases. They're cases where it would be wrong/impossible to have a default constructor. |
Yes, that seems correct. |
Related ceylon/ceylon-compiler/issues/2329. |
This is turning out to be quite difficult because I need the constructor to initialize |
And the javac AST you're building doesn't let you iterate over all the fields you've added to it?! |
I think we should put this has-a-field information in the model, is that OK with you @gavinking? In fact if we added an |
I would have thought this information was there in the javac AST. |
That would work, @gavinking, but the transformers have always steered clear from inspecting the emitted JCTree. It would be too easy to get into ordering problems where we decide X, then something goes and adds Y which invalidates the logic for X. But maybe that's the simplest solution in this case. |
I mean, while I agree that in general it might be a bad idea, it seems like it's the most correct thing here. |
This constructor ends up looking an awful lot like the constructor we generate for |
I mean we could say that only |
No, I don't really see any either. It just seems like there's a small opportunity here to keep things simpler... |
Also apply it to AssertionError. Part of ceylon/ceylon-spec#1405
This should now be done. |
Great, thanks! |
If we could write this :
it would allow to generate a private default constructor in Java for the frameworks that need it.
For instance, currently this JPA entity with FIELD access
https://github.com/sgalles/ceylon-dddsample/blob/master/source/dddsample/cargotracker/domain/model/cargo/Cargo.ceylon
must have this constructor to please the compiler.
but it could simply be
abstract new(){}
The text was updated successfully, but these errors were encountered: