Replace DDIC objects

[mbtools]

Replace the two DDIC objects with type definitions in the code

[dominikpanzer]

do you see any problems regarding the ddic objects? I personally find them more comfortable to use than integrated type definitions.

[mbtools]

it becomes more difficult if you want several implementations of the result class. I see repos like this as reusable libraries. [one day we will get a package manager ;-)]

Imagine abapGit would use a copy like zcl_abapgit_result and then logger with zcl_logger_result. They could be different versions of "result library". Instead of copying just the class (and exceptions), you have to duplicate also DDIC and adjust the code accordingly.

In general, the less objects the better.

[dominikpanzer]

interesting. because you brought up the example: so the general ABAPGIT way of dependency management is to copy every dependency into the ZABAPGIT* namespace instead of using the original version and using inheritance or whatever? so it can be installed easily and no "real" dependency-management is needed?

[mbtools]

vendoring (bundled deps) is a way to have several versions of the same code. in js different versions are simply in different folders. in abap, you can do the same using namespaces (/mbtools/cl_logger, which I like to see as a "one-level folder structure") or prefixes (zcl_abapgit_logger) or just some other name. this has it's pros and cons. the key is to have an automated way to update the dep (if and when you want). in abapgit, we use this mechanism for https://github.com/abapGit/abapGit/tree/main/src/json and have automated the mirror and rename with abaplint. I use it for three repos to mirror into MBT. it works quite well.

to be clear, abapgit is not imposing any way or preference here. dep management is not the scope of a git client. that would be the purpose of "apm" (someday :-) ).

[dominikpanzer]

thanks for the insights Marc! I moved the ddic-structures/table types to local types. enjoy