3 ms·
Great point. We use method/class names in config files that get parsed and dynamically evaluated. You could break the whole application by changing class names
by splittingTimes 5y ago
Great point. We use method/class names in config files that get parsed and dynamically evaluated. You could break the whole application by changing class names as an init config could fail.
Also persisting stuff in customer DBs that depends on class names (and reflection) is nice source of terror. Shipping a new version of your software with a refactored class names corrupts the whole DB of a customer.
- Zababa 5y ago> Also persisting stuff in customer DBs that depends on class names (and reflection) is nice source of terror. We do that but with XML files, most of our tables are dynamically generated. I'm a bit scared every time I touch this part.
- splittingTimes 5y agoWe have a whole framework that handles migrations of costumer DBs after updates. But when you don't even know that your changed class gets persistent (because of spaghetti inheritance/type hierarchy) and you do not enter it in the migration scripts, you duck up.