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

Empty object not reflected in generated wrapper #309

Closed
carueda opened this issue Dec 13, 2024 · 1 comment
Closed

Empty object not reflected in generated wrapper #309

carueda opened this issue Dec 13, 2024 · 1 comment
Assignees

Comments

@carueda
Copy link
Owner

carueda commented Dec 13, 2024

Describe the bug

Empty object not properly handled.

To Reproduce

Basic repro steps:

  1. Input config schema (say in a file empty0.spec.conf):

    emptyObj : {}
  2. Generate wrapper as usual, eg:
    java -jar tscfg-x.y.z.jar --spec empty0.spec.conf --scala --cn Empty0

Expected behavior

An EmptyObj class included in the generated code, to reflect the input empty object emptyObj:

final case class Empty0(
  emptyObj : Empty0.EmptyObj
)

object Empty0 {
  final case class EmptyObj(
  )
  ...
)

However, the following is generated:

final case class Empty0(
)
...

Additional context/comments

An empty object per se might not be a typical use case, but the issue becomes significant when using it in combination with the extends mechanism. Here's a more realist example:

#@define abstract
SomeAbstract {
  something: string
}

#@define extends SomeAbstract
SomeExtension {
}

foo: SomeExtension

As in the simpler case above, the SomeExtension definition also gets lost, but in this case actually breaking the intended behavior, which is to have a class SomeExtension with the members obtained from the extended class!

@sebastian-peter – just fyi as I'm also just noting this issue seems to be affecting some of your projects. Sorry for the trouble. Time has been very scarce for me for a good while, but I still have plans for tscfg in the future, but for now hoping to address this issue soonish.

@carueda carueda self-assigned this Dec 13, 2024
carueda added a commit that referenced this issue Dec 13, 2024
carueda added a commit that referenced this issue Dec 16, 2024
fix #309 "Empty object not reflected in generated wrapper"
@carueda
Copy link
Owner Author

carueda commented Dec 16, 2024

@ckittl @johanneshiry @sebastian-peter @t-ober – sorry for the mass tagging, but I continue to appreciate your use of tscfg for Simona (great use case!), and wanted to bring to your attention this fix, now included in the just released tscfg 1.1.5, which should also fix the closely related issue of resolving string type instead of @define.

Along with own unit tests in this repo, I have also tested it with Simona's config-template.conf, both in that current form and also with the removal of the "tricks" you have put in place due to the bad handling of empty objects (see diff below).

BTW, I understand you’ve been considering an alternative configuration strategy for Simona, which is entirely reasonable. Unfortunately, tscfg development has become somewhat ad hoc and sporadic in recent years, especially as new features were added—sometimes without much elegance. That said, if you're still interested, I’ve begun working on a new design and cleaner implementation in a private repository. The goal is to make maintenance, improvements, and contributions significantly easier. However, I’m not sure when I’ll be able to integrate these changes into the main codebase. You’ve been fantastic contributors to tscfg, and I’d be delighted to share the repo (and ideas) with anyone interested.


index 6c9d88671..48f584ceb 100644
--- a/src/main/resources/config/config-template.conf
+++ b/src/main/resources/config/config-template.conf
@@ -30,34 +30,24 @@ LoadRuntimeConfig {

 #@define extends BaseRuntimeConfig
 FixedFeedInRuntimeConfig {
-  baseRuntimeConfig: BaseRuntimeConfig # this entry is ignored by the config generator,
-  # but cannot removed bc otherwise FixedFeedInRuntimeConfig is handled as String
 }

 #@define extends BaseRuntimeConfig
 PvRuntimeConfig {
-  baseRuntimeConfig: BaseRuntimeConfig # this entry is ignored by the config generator,
-  # but cannot removed bc otherwise PvRuntimeConfig is handled as String
 }

 #@define extends BaseRuntimeConfig
 WecRuntimeConfig {
-  baseRuntimeConfig: BaseRuntimeConfig # this entry is ignored by the config generator,
-  # but cannot removed bc otherwise WecRuntimeConfig is handled as String
 }

 #@define extends BaseRuntimeConfig
 EvcsRuntimeConfig {
-  baseRuntimeConfig: BaseRuntimeConfig # this entry is ignored by the config generator,
-  # but cannot removed bc otherwise EvcsRuntimeConfig is handled as String
   chargingStrategy: String | "maxPower" # can be one of maxPower, constantPower, gridOrientedScheduling or marketOrientedScheduling
   lowestEvSoc: Double | 0.2 # Defines the lowest possible state of charge (SoC) that an EV is allowed to uncharge in vehicle to grid (V2G) mode
 }

 #@define extends BaseRuntimeConfig
 StorageRuntimeConfig {
-  baseRuntimeConfig: BaseRuntimeConfig # this entry is ignored by the config generator,
-  # but cannot removed bc otherwise StorageRuntimeConfig is handled as String
   initialSoc: Double | 0 # Defines initial soc of storages as a share of capacity, 0-1
   #@optional
   targetSoc: Double
@@ -65,20 +55,12 @@ StorageRuntimeConfig {

 #@define extends BaseRuntimeConfig
 EmRuntimeConfig {
-  # # # # #
-  # ATTENTION: calculateMissingReactivePowerWithModel and scaling is ignored here.
-  # Cleaner solution is possible with different config framework.
-  # # # # #
-  baseRuntimeConfig: BaseRuntimeConfig # this entry is ignored by the config generator,
-  # but cannot removed bc otherwise EmRuntimeConfig is handled as String
   curtailRegenerative: Boolean | false
   aggregateFlex: String | "SELF_OPT_EXCL_REG"
 }

 #@define extends BaseRuntimeConfig
 HpRuntimeConfig {
-  baseRuntimeConfig: BaseRuntimeConfig # this entry is ignored by the config generator,
-  # but cannot removed bc otherwise HpRuntimeConfig is handled as String
 }

carueda added a commit that referenced this issue Dec 16, 2024
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

1 participant