Skip to content

Conversation

@wencagh
Copy link

@wencagh wencagh commented Jun 6, 2024

It is sometimes useful to have option map StdClass object directly, because it is very often returned from other API clients implementations. It make no sense to encode response from other libraries to json to be decoded in next step in map function to StdClass object back.

@BenMorel
Copy link
Member

BenMorel commented Jan 3, 2026

Hi, there are a couple things bothering me here:

  • this is a json-to-object mapping library, so it feels slightly odd for the main JsonMapper class to also map from an object
  • if we're going to do this, we should rename mapToObject(), as the name does not clearly convey its intended meaning

Also, you changed the package name in composer.json in your PR!

@coveralls
Copy link

Coverage Status

coverage: 92.475%. remained the same
when pulling f55bce2 on wencagh:main
into 74254ad on brick:main.

@BenMorel BenMorel force-pushed the main branch 3 times, most recently from 58a6b1f to 62cb8bb Compare January 3, 2026 01:21
@wencagh wencagh force-pushed the main branch 2 times, most recently from 22500f6 to f6404c8 Compare January 3, 2026 12:59
@wencagh
Copy link
Author

wencagh commented Jan 3, 2026

Sorry of the last commit with package rename. It was accidentally pushed, after I rebase my fork.

As I mention, in my case I use this library in combination with another one, wich give me response (originaly in JSON) but automatically transformed to StdClass (no simple option how to change this behaviour]. Without making mapToObject public, there will be need to encode it back to JSON and then call map -> back to StdClass and then map it.

In question of changin name of the method, will be OK mapToObject -> mapStdClassToObject ?

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants