<div dir="ltr">Hi Bert,<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 16, 2016 at 11:50 AM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-">On Fri, Dec 16, 2016 at 11:32 AM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Instead of checking for "understands" we should use valueOfFlag: (which defaults to false) to get back the old behavior. Or we recreate the preference. Or we make it into a "pragma" preference on some class (which seems to be the preferred way nowadays, even though it leads to an explosion of pref accessor methods?)</div></div></div></div></blockquote><div><br></div></span><div>Well, the current scheme leads to an explosion of preference accessor methods in Preference class.</div></div></div></div></blockquote><div><br></div></span><div>Well, only because SomeOne™ changed the accessors generator to actually put them into the package, when they used to be in their own "*autogenerated" package.</div></div></div></div></blockquote><div><br></div><div>Ah.  Indeed,  That's the bug.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>These accessor methods are only there to speed up the DNU, which is the default handler. Maybe on Cog we don't even need the precompiled accessors.</div></div></div></div></blockquote><div><br></div><div>While MNU is much faster in contexts like proxies on Cog, its not going to speed up occasional use.  However, in a tight loop it does help.  </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>  I think the pragma style is far more preferable to this. </div></div></div></div></blockquote><div><br></div></span><div>I think pragmas are good for finding preference declarations. </div></div></div></div></blockquote><div><br></div><div>We're in agreement.  The pragma approach has two main advantages; one it to identify and allow documenting methods that provide preferences, the other is in being modular, in that the pragma method can live in the package to which it belongs.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>But having to implement preference storage over and over again is not the best solution. But that's what the current pragma prefs require - a setter and a getter and a class var and logic for initialization and if a class has many prefs then maybe a prefs dictionary because too many class vars are annoying etc. pp.</div></div></div></div></blockquote><div><br></div><div>Well, in the case where code wants to update the preference I think the setter is acceptable,.  But it ould be nice if the Preferences package could infer how to set the variable from the getter, something i think is fairly trivial if the getter returns a class var (or even a class inst var?).  Also, the getter can (and should) provide the initialization if the body is written as</div><div><br></div><div>    ^Var ifNil: [Var := true/false/aSymbol]</div><div><br></div><div>So with this approach and help from the Preferences framework one should be able to get away with just the getter, whose pragma should; include the help[ text, etc, and the revised class definition to declare the class var.  I'm happy to pay that cost for the modularity and documentation.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Having actual Preference objects managed by a Preferences class takes care of all of that, once and for all.<br></div></div></div></div></blockquote><div><br></div><div>The main problem is that while a preference object can encapsulate the same state as the pragma preference getter method, one also needs code to create the object and add it to the framework.  It's that that makes the two essentially similar in cost, and makes me dislike the preference objects.  The preference getter method stands alone, and so can be added and removed freely.  In a class such as Compiler or Parser where one may have several preferences, one ends up having to edit the method that adds preferences whenever adding or removing a preference.  There's a collision.  The pragma approach solves these collisions by providing an implicit way to add a complex object.  Its analogous to how pragma menu actions allow menus to be extended without collision between different extensions.  But to achieve this elegance the pragma scheme must be thought through; for example extending the Preference system to allow preferences to be set without needing preference setter methods (and maybe even modifying the compiler to declare variables in pragma preference methods as class vars?).</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> At least one doesn't have the System package being marked as dirty just because preferences have been accessed.</div></div></div></div></blockquote><div><br></div></span><div>See above - that's a bug IMHO.</div></div></div></div></blockquote><div><br></div><div>+1</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I agree that a default MNU that answers false, and doesn't create an accessor method, is a good default.  Although it does suffer the disadvantage that a misspelled reference will simply go unnoticed, defaulting to false.</div></div></div></div></blockquote><div><br></div></span><div>True. Maybe in a dev image it indeed should raise an exception.</div><div> </div><div>Btw, this is a good discussion :)</div></div></div></div></blockquote><div><br></div><div>+1</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-HOEnZb"><font color="#888888"><div>- Bert -<br></div></font></span></div></div></div></blockquote><div> </div></div><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>