Conversation
Signed-off-by: Tom <tom@temper.systems>
Signed-off-by: Tom <tom@temper.systems>
Signed-off-by: Tom <tom@temper.systems>
Signed-off-by: Tom <tom@temper.systems>
Signed-off-by: Tom <tom@temper.systems>
Signed-off-by: Tom <tom@temper.systems>
| ), | ||
| ) | ||
| internal fun allowWarnings(pos: Position) = run { | ||
| // Separate them with `warnings` first, to prevent warnings against the other on older rust. |
There was a problem hiding this comment.
At least, I seemed to see effects per the comment above, but I didn't spend a lot of time on this aspect.
| private var insideMutableType = false | ||
| private val failVars = mutableSetOf<ResolvedName>() | ||
| private val functionContextStack = mutableListOf<FunctionContext>() | ||
| private val logSink = LogSink.devNull // TODO what? |
There was a problem hiding this comment.
I need some log sink, and this works for now, but maybe should reconsider or even just pass log sinks into translators. I've wanted that more than once before.
| // Build the builder. | ||
| // Here we make `WhateverBuilder` for requireds and/or `WhateverBuilderOptions` structs for optionals. | ||
| // Build the maker. | ||
| // Here we make `WhateverMaker` for requireds and/or `WhateverMakerOptions` structs for optionals. |
There was a problem hiding this comment.
I think Builder is more idiomatic, but I think people will cope.
| ): List<Rust.Item> = run { | ||
| // We're here because this class has no matching member, so walk its supertypes to match the super method. | ||
| // The method we inherit closest might be on a different branch. | ||
| val overrides = findOverrides(decl.typeShape, superShape, typeContext, logSink) |
There was a problem hiding this comment.
I factored out findOverrides from existing logic. I think it meets the needs here.
| addAll(argIds) | ||
| }, | ||
| ) | ||
| } |
There was a problem hiding this comment.
This is now factored to share logic with trait-wrapper-to-trait forwarding that I put in on the previous pr. The main difference is what happens inside the forwarding method, so that's what the callback is for.
| | } | ||
| | fn whatever(& self) -> std::sync::Arc<String> { | ||
| | BTrait::whatever(self) | ||
| | } |
There was a problem hiding this comment.
Explicitly call B's whatever, since that's the resolution found.
There was a problem hiding this comment.
Explicitly call B's
whatever, since that's the resolution found.
Actually, that just results in infinite recursion when the impl is for B, because it just comes back here. Instead just allow the BTrait default implementation to be called implicitly.
| | fn set_prop(& self, value: std::sync::Arc<String>) { | ||
| | ATrait::set_prop( & ( * self.0), value) | ||
| | } | ||
| |} |
There was a problem hiding this comment.
This trait wrapper to trait stuff isn't new, but interface D is new in the test case, so it's extra lines in the codegen here.
| | } | ||
| | fn set_prop(& self, value: std::sync::Arc<String>) { | ||
| | DTrait::set_prop(self, value) | ||
| | } |
There was a problem hiding this comment.
Call A for greeting implicitly, B for whatever, and own F impl for thing. Others are picked up by D.
This looks correct to me by eyeball check vs the temper code above, but I haven't tested the new code to compile and run with rust yet.
|
|
||
| @Test | ||
| fun needlesslyGenericBuilder() { | ||
| fun needlesslyGenericMaker() { |
There was a problem hiding this comment.
This case still is for testing #271, and I still haven't fixed that issue.
|
|
||
| member.overriddenMembers = overriddenMembers.toSet() | ||
| return overriddenMembers.toSet() | ||
| } |
There was a problem hiding this comment.
Factored out a new public function for use in be-rust. I can't just use overriddenMembers (as also discussed in comments), because I need to know the overrides for methods that don't exist directly in the base type.
Signed-off-by: Tom <tom@temper.systems>
| } | ||
| // TODO Ensure unique names. | ||
| val builderId = "${targetId.outName.outputNameText}Builder".toId(targetId.pos) | ||
| val builderId = "${targetId.outName.outputNameText}Maker".toId(targetId.pos) |
There was a problem hiding this comment.
Do you prefer Maker to Builder?
There was a problem hiding this comment.
Do you prefer Maker to Builder?
I prefer Builder because it's more idiomatic. I was just trying to be friendlier with Temper conventions.
That said, I have a new idea. I was trying to make one branch for all the outstanding issues again, but since I've gotten the pivot, I can't finish it immediately, anyway. I'll back out the Builder changes from this pr, so I can reassess later.
There was a problem hiding this comment.
I've backed out the Builder renaming and written issue #367 about a different strategy to be both idiomatic and more often avoid naming conflicts.
Signed-off-by: Tom <tom@temper.systems>
| fn.parameters.restParameter != null && return | ||
| // Build the builder. | ||
| // Here we make `WhateverBuilder` for requireds and/or `WhateverBuilderOptions` structs for optionals. | ||
| // Here we make `WhateverBuilder` for requireds and/or `WhateverOptions` structs for optionals. |
There was a problem hiding this comment.
Noticed in passing that this comment was wrong vs current behavior.
2 participants
Uh oh!
There was an error while loading. Please reload this page.