Timeline for Problem with runaway number of properties
Current License: CC BY-SA 4.0
29 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 29, 2020 at 20:18 | answer | added | gnasher729 | timeline score: 0 | |
| Apr 29, 2020 at 3:05 | answer | added | Jared Goguen | timeline score: 0 | |
| Apr 28, 2020 at 22:35 | vote | accept | timbo | ||
| Apr 28, 2020 at 3:01 | history | tweeted | twitter.com/StackSoftEng/status/1254968833988755456 | ||
| Apr 28, 2020 at 2:23 | comment | added | rwong | EXIF allows for a limited number of data representation types (strings, integers, datetime, etc). The backend is a byte array. You can implement conversion functions. | |
| Apr 27, 2020 at 19:34 | answer | added | JimmyJames | timeline score: 1 | |
| Apr 27, 2020 at 18:23 | answer | added | gnasher729 | timeline score: 2 | |
| Apr 27, 2020 at 11:01 | answer | added | Nat | timeline score: 0 | |
| Apr 24, 2020 at 17:56 | comment | added | Doc Brown |
@timbo: who says its not elegant? For reporting, it is not unusual to require every property as a string. In case you don't do any calculations or evaluations in the reporting modules, why bother with a T GetProperty<T>at all? Why not have a method string GetProperty(propertyId, formatHint=null) instead?
|
|
| Apr 24, 2020 at 17:46 | comment | added | timbo | @DocBrown It seems you are suggesting my final approach might be the best I can do? I'm starting to feel that might be the case. I've gone through dozens of such issues in this code base, and always had nice elegant solutions before. Maybe I just have to accept there aren't always nice elegant solutions to every problem and just accept the compromise. | |
| Apr 24, 2020 at 17:44 | comment | added | timbo | @Turksarama I definitely could be. I mean, I am, but both many interfaces and one interface feel bad, but with different problems. | |
| Apr 24, 2020 at 17:43 | comment | added | Doc Brown |
"It still feels bad. It removes compile-time type checking." - that is your problem. You are trained way too much in "everything must be compile-time checked" that you overlook that compile time checks and run-time checks are nothing but a trade-off. For some use-cases, compile checks are more appropriate. For reporting, your HasProperty approach is fine, and the fact there is no compile-time safety is simply worth it. You can try to balance this by automated tests,
|
|
| Apr 24, 2020 at 17:42 | comment | added | timbo | @Nat I hope the re-write helped. | |
| Apr 24, 2020 at 17:42 | comment | added | timbo | @ewhiting It definitely could be inheritance. If I had a single Image and just PNG and Jpeg, no problem. The problems here are the scale, and the frequent addition of unforseeable properties. It can, and has, been implemented with hundreds of subclasses. It causes huge numbers of ifs and switches to deal with though. Interfaces simplified it a bit (a lot actually) but left a lot to be desired. | |
| Apr 24, 2020 at 17:40 | comment | added | timbo | @DocBrown Also, as I think Flater is getting at, null can be distinct from not having the property, or from not supporting it. It might be that the property exists, but the value actually recorded is null. | |
| Apr 24, 2020 at 17:37 | comment | added | timbo | @DocBrown I think that it can be implemented with nullable types. I've never seen a huge advantage outside of databases; they are basically implemented as a bool and the type slapped together anyway. The implementation is something I never dictate in an interface, so certainly it could be implemented with nullable types, I just chose not to. Likewise, I could get rid of "HasProperty" and dictate that if the property doesn't exist, return null. It is something I'm happy to discuss, but I don't think it leads to a solution of the core problem here. | |
| Apr 24, 2020 at 17:29 | history | edited | timbo | CC BY-SA 4.0 |
Re-wrote the question in response to feedback
|
| Apr 14, 2020 at 9:59 | answer | added | Simon B | timeline score: 3 | |
| Apr 14, 2020 at 5:34 | comment | added | Doc Brown | @Flater: I want to know from the OP what semantics these boolean/value pairs express in their real situation. Sure we can "invent" cases where such a pair makes sense, but I am really interested what the OP has to say about it. | |
| Apr 14, 2020 at 0:55 | comment | added | Turksarama | It's hard to tell because not much information is given, but my gut feeling is that you're trying to force one interface to do the job of many interfaces. You can, and sometimes should, have more than one interface on a class. | |
| Apr 13, 2020 at 23:25 | comment | added | Nat | Like, if I had to guess how to write an answer to this question, I might start out by discussing how designing a class-tree (or whatever) requires starting from a top-down approach, where you understand the domain and break it down into chunks, as opposed to a bottom-up approach in which you'd try to create chunks to combine. I'd speculate that, when you're trying to refactor, you're designing little chunks of logic along the way, then trying to merge them -- resulting in a big mess. Still, that'd largely be speculation. | |
| Apr 13, 2020 at 23:15 | comment | added | Nat | To fix this, might help to go in one of two directions: (1) Give tons of details. Show the starting point, and where it ended up. (Perhaps on SE.CodeReview, instead?) Point out the parts of the process that you're concerned about and why, then ask how the concerns could be addressed. (2) Instead of asking about what you might be doing wrong, describe the general problem and ask how it could be solved correctly. | |
| Apr 13, 2020 at 23:10 | comment | added | Nat | This question statement is a bit short on details to determine the problem. I mean, if you were doing everything perfectly correctly and not encountering any problems, then that'd actually tell us more; but, since there're a million different ways in which an otherwise-correct approach can go astray, it's hard to guess which specific potential issue you might be encountering. | |
| Apr 13, 2020 at 20:11 | answer | added | Flater | timeline score: 6 | |
| Apr 13, 2020 at 19:58 | comment | added | ewhiting |
Is it viable to make IThing a supertype and build Things as subtypes? You say you have attributes "all" Things support, and attributes only "some" Things support, that sounds like an inheritance problem to me, am I wrong?
|
|
| Apr 13, 2020 at 19:58 | comment | added | Flater | @DocBrown: I'm not suggesting OP's approach doesn't have flaws, but nullables aren't always the answer, e.g. when null itself is a meaningful value and not the same as when the boolean is false. | |
| Apr 13, 2020 at 19:23 | comment | added | Doc Brown |
If you use a boolean for every property to indicate if it has a value, why not simply use nullable types and null? Like int? SpecialNumber? If your interface needs all those properties is a different question, maybe it does, but that is hard to answer by looking at meaningless terms like Thing, without knowing the precise requirements.
|
|
| Apr 13, 2020 at 18:05 | review | First posts | |||
| Apr 19, 2020 at 8:33 | |||||
| Apr 13, 2020 at 18:02 | history | asked | timbo | CC BY-SA 4.0 |