-
Notifications
You must be signed in to change notification settings - Fork 29
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
Support additional application actions while registering an application #137
Comments
Been thinking a bit about this, and I think it'd be best to extract this into a separate class whose constructor takes the We can keep this method as-is (without the map) then as a high-level alias. |
We already have such class, it's the I think that we should honor such design decision and don't start adding lot's of classes to the Disclaimer: We would need a magic orb to know how a given piece of software will evolve in order take the perfect design decisions at this point. |
So your "solution" is to add 10 overloads for one method with different params? |
I think for 1.0 things are good enough as-is. But we should perhaps bear in mind such things for a future version 2. |
Who said 10? My solution is to strictly add those features that are common and prone to errors or different behaviours when implemented by the clients. So regarding to the desktop entries only one more function overload will be required. |
One is clearly ambiguous to use. A method with more than one parameter taking a default is IMO bad design and really error prone. For yours to use I have to either fill something into the first map, or I have to pass an empty map and fill into the second, or pass two and really pay attention not to mix up. I can't see whether I'm doing it right though, without having a good IDE that shows me the parameter names and docs where the call is, because that's where I need that information to see if it's used right. An object where I use setters with really obvious names isn't prone to errors, from the users' view at least. Edit: That's something I don't like about Qt by the way. It surely keeps code somewhat compact, but it forces me to use some IDE to see if things are right. If I for instance look at code on GitHub I have big issues to validate calls. Hence I personally tend to use setters where possible with Qt. It's an important design rule to only require really essential data in constructors, and allow for setting the rest with setters instead of constructor arguments. Functions are difficult here, as there's no way to use "setters" or anything. Some people pass "configuration objects" to functions to work around that limitation, but that then is clearly a |
This is a feature feature from AIL that is quite useful. Implementing it directly on the register method will save re-opening and re-editing the desktop file. Here is a draft of the method declaration.
The text was updated successfully, but these errors were encountered: