Timeline for How can I work out which functions work with SetOptions?
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 23, 2017 at 12:35 | history | edited | CommunityBot |
replaced http://stackoverflow.com/ with https://stackoverflow.com/
|
|
| Jan 21, 2012 at 9:05 | comment | added | Leonid Shifrin |
@Mike I think, the whole fact that global options settings do not work even for some built-in functions (which I think can be qualiied as a bug) shows the fragility of the approach based on global options settings (note that SetOptions does work, in the sense that options really get reset. They are just not used!). I agree with you and Mr.Wizard when I look at it from the end-user's viewpoint, but my post was from the developer's viewpoint, and I think most expert users who write packages would be better off using developer's viewpoint most of the time. My two cents.
|
|
| Jan 20, 2012 at 23:31 | comment | added | Mike Honeychurch |
Although this answer doesn't address the question it references a useful approach to dealing with options so I don't think it should be deleted. On the debate about the use of SetOptions I am with Mr Wizard. As an example, for my system, not used by any other person, I have Joined->True for DateListPlot in my init.m because there have never been cases where I personally wanted to see a plot with Joined->False.
|
|
| Jan 20, 2012 at 18:13 | comment | added | Mr.Wizard | Chat please, if you have time: chat.stackexchange.com/rooms/2266/leonid-mr-wizard | |
| Jan 20, 2012 at 18:06 | comment | added | Leonid Shifrin |
@Mr.Wizard I think you missed my point. For an (user)-extensible system, there should be virtually no difference between system functions and those provided by users. This is the key to success, as long as the development done by a community is concerned. And if you look at the package-writing guidelines, one of the main ones is "make your function behave as much like a built-in as possible". So, ideally, there is no difference. The same customization of the system can be made with locally-passed options, with a mechansim I specified, but in a much safer way. I never use SetOptions myself.
|
|
| Jan 20, 2012 at 17:31 | comment | added | Mr.Wizard | I think we are using global options differently. If they are for a custom function, sure, why not use them for required functionality. But for a system function I think it is Bad Form to mess with global options as part of a package, as I feel they are there for customization of the system. If I set all my FontSize options to huge because of eyesight, I want that setting to persist without having to use custom wrappers, and if someone's package changes that setting I am going to get upset. | |
| Jan 20, 2012 at 17:25 | comment | added | Leonid Shifrin | @R.M. Well, thanks, that makes sense. Will let it live then :) | |
| Jan 20, 2012 at 17:24 | comment | added | Leonid Shifrin |
@Mr.Wizard You don't have to explain your voting, but I appreciate that you did - thanks! Now, "because Mathematica is often an individually used and individualized software. I would however be concerned by packages that changed my options without notice!" - but don't you see that there is no clear border between the two, as soon as people start really using each other's packages? A person A creates a useful package a.m and resets options of say Grid, and a.m crucially depends on that. A person B creates b.m and resets options of Grid differently. A person C wants to use a.m and b.m ...
|
|
| Jan 20, 2012 at 17:20 | comment | added | rm -rf♦ | @LeonidShifrin No, please don't delete. An answer is always useful if it adds anything of substance to solving/understanding the question. Sometimes (generally, not specific to this), such answers can also be helpful in figuring out the underlying problem or if it's a conceptual misunderstanding on the OP's part. Deleting should be reserved for answers that talk of football when the question is on tennis. I can understand people not wanting to vote, but that doesn't diminish the usefulness. | |
| Jan 20, 2012 at 17:17 | comment | added | Mr.Wizard | Please do not delete it; again I know (or at least presume) that you cannot see my votes, but I still feel the need to explain why I don't vote for an otherwise thoughtful answer. I do not share your blanket distaste for global options, because Mathematica is often an individually used and individualized software. I would however be concerned by packages that changed my options without notice! | |
| Jan 20, 2012 at 17:09 | comment | added | Leonid Shifrin | @Mr.Wizard You are right that this does not address the direct question, but I clearly stated so, and also I think it addresses the reason for this question. If I get lots of negative feedback on this from others, I may delete this answer and just incorporate this in the book. | |
| Jan 20, 2012 at 17:07 | comment | added | Leonid Shifrin |
@Mr.Wizard I wanted to make this a comment, but it was too large for that. I actually strongly dislike resetting options globally (SetOptions), particularly for system functions, but also generally. I think this practice should be officially discouraged, since it changes the global state of the system. As soon as their will be many interdependent third-party applications / packages in widespread use, (and I hope this will happen, for the sake of Mathematica community), the use of SetOptions will create nothing but problems. My personal view, of course.
|
|
| Jan 20, 2012 at 17:01 | comment | added | Mr.Wizard | In a rare turn of events I shall not vote for your answer as I don't believe it addresses the question asked. (but I'll go find another answer of yours I haven't seen yet and vote for that to compensate) | |
| Jan 20, 2012 at 16:56 | history | answered | Leonid Shifrin | CC BY-SA 3.0 |