<div dir="ltr">Hi All,<div><br></div><div> replying to an earlier message now we have a good subject line :-)</div><div><br></div><div><br><div class="gmail_quote">On Sat, Dec 17, 2016 at 2:25 PM, Chris Muller <span dir="ltr"><<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</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">Gentlemen, may I ask what you thought of my list of requirements?<br><br> <a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2016-March/188486.html" rel="noreferrer" target="_blank">http://lists.squeakfoundation.<wbr>org/pipermail/squeak-dev/2016-<wbr>March/188486.html</a></blockquote><div><br></div><div>I like some of them. To be specific...</div><div><br></div><div>1. I see no need for Preferences except as a UI tool. Preferences are used to control parts of the system that can have useful alternative behaviors. Having a Preferences UI is useful as it</div><div>- informs the user of the set of available preferences and documents them</div><div>- provides a convenient UI for setting them</div><div>But it is /much/ more preferable for the code that is affected by a given preference to use its own state to determine the value of the preference:</div><div>- the application can continue to work if Preferences is unloaded</div><div>- the application does not have to restrict itself to the Preferences style and can use something it finds convenient</div><div><br></div><div>2. very useful; can easily be derived from pragma preferences</div><div><br></div><div>3. Not sure symbolic names are useful. A user readable name is useful, but an additional symbolic name is just cruft</div><div><br></div><div>4. OK, again something that can be included in pragma preferences (and indeed derived from code if the pragma method is stereotypical enough; which it should be)</div><div><br></div><div>5. Not sure preferences need to specify the domain of values; boolean preferences are easy, but, take, say, a repository URL. I don't think it makes sense to restrict this to a fixed set of valid URLs. So not too sure about 5.</div><div><br></div><div>6. Sure. Again something that can be done with pragma preferences</div><div><br></div><div>7. Sure. Can be constructed from 2. 4. and ability to access current value.</div><div><br></div><div>7.5, 7.6 why? Don't see any pressing need for these. Seem to be forcing a Dictionary implementation.</div><div><br></div><div>8. Sure. Again a preference saving/loading mechanism is not antithetical to pragma preferences.</div><div><br></div><div>9. Sure</div><div><br></div><div>10. That's what pragma preferences do. That's one of the major advantages of pragmas in general. They allow code to be labelled with semantic information that applies not to the code's function, but to its context in a broader system. They allow that labelling to be associated with the code to be labelled, not be in a collection of labelling that collide when considering different sets of code to be labelled.</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">These were derived through careful consideration of the real-world use<br>cases, both for Squeak and external applications. They are open for<br>discussion, of course!<br><br>We don't need a special language feature to provide a simple and<br>elegant wrapping of a Dictionary. We just need to get back to<br>Smalltalk and objects.<br></blockquote><div><br></div><div>Um, why is a Dictionary a valid representation of preferences? A dictionary might adequately tell us the current state of the system's preferences. But as we've seen above we need a lot more, default value, documentation, UI for changing, save/load framework.</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"><span class="gmail-">> We're in agreement. The pragma approach has two main advantages; one it to<br>> identify and allow documenting methods that provide preferences,<br><br></span>I honestly think we don't need pragmas to do it.<br></blockquote><div><br></div><div>I was agreeing with Bert, not you. You and I clearly disagree.</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"><span class="gmail-">> the other<br>> is in being modular, in that the pragma method can live in the package to<br>> which it belongs.<br><br></span>Let's not let package concerns dictate the design. Let's make the<br>right design for users, *then* optimize out any packaging issues that<br>may arise. There's no reason Preference accessors can't just as<br>easily live in the package they belong without needing to use pragma's<br>and class-vars.<br></blockquote><div><br></div><div>This is not about Monticello packages. It is about complex systems being composed of components. Of course I want to deploy a system which is a subset of a more complex one. Of course I should be able to discard the Preference UI if my application doesn't (or more importantly, can't or shouldn't) support it.</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"><span class="gmail-">>> But having to implement preference storage over and over again is not the<br>>> best solution. But that's what the current pragma prefs require - a setter<br>>> and a getter and a class var and logic for initialization and if a class has<br>>> many prefs then maybe a prefs dictionary because too many class vars are<br>>> annoying etc. pp.<br>><br>><br>> Well, in the case where code wants to update the preference I think the<br>> setter is acceptable,. But it ould be nice if the Preferences package could<br>> infer how to set the variable from the getter, something i think is fairly<br>> trivial if the getter returns a class var (or even a class inst var?).<br>> Also, the getter can (and should) provide the initialization if the body is<br>> written as<br>><br>> ^Var ifNil: [Var := true/false/aSymbol]<br><br></span>That's what I thought too, and why I originally argued against<br>answering arbitrary default value of false, before agreeing, but then<br>someone mentioned that the developer could have easily misspelled it,<br>causing a hidden bug. I couldn't agree more, and that seems like it<br>really dilutes any net gain for the user. Its complex and magic,<br>instead of just simple.<br></blockquote><div><br></div><div>It's not complex or magic. It's code. It's an assignment. The "magic" is the ability to decorate that code with information that</div><div>- states that this is a system preference</div><div>- documents its purpose</div><div>- identifies it to tools that want to collect the set of system preferences</div><div>- etc</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"><span class="gmail-">> So with this approach and help from the Preferences framework one should be<br>> able to get away with just the getter, whose pragma should; include the<br>> help[ text, etc, and the revised class definition to declare the class var.<br>> I'm happy to pay that cost for the modularity and documentation.<br>><br>>> Having actual Preference objects managed by a Preferences class takes care<br>>> of all of that, once and for all.<br>><br>><br>> The main problem is that while a preference object can encapsulate the same<br>> state as the pragma preference getter method, one also needs code to create<br>> the object and add it to the framework. It's that that makes the two<br>> essentially similar in cost, and makes me dislike the preference objects.<br>> The preference getter method stands alone, and so can be added and removed<br>> freely. In a class such as Compiler or Parser where one may have several<br>> preferences, one ends up having to edit the method that adds preferences<br>> whenever adding or removing a preference. There's a collision. The pragma<br>> approach solves these collisions by providing an implicit way to add a<br>> complex object. Its analogous to how pragma menu actions allow menus to be<br>> extended without collision between different extensions.<br><br></span>A pure-Smalltalk pattern can do it. If we want to co-locate access<br>and the default value in a lazy accessor like this.<br><br> somePreference<br> ^ (Preferences somePreference ifNil:<br> [ Preferences<br> addPreferenceNamed: #somePreference<br> description: 'When true it means...'<br> default: theDefaultValueForSomePreferen<wbr>ce ]) value<br></blockquote><div><br></div><div>As others have said the above is way more complex than a pragma preference. It also ties the application to the Preference UI.</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"><br>#somePreference resides in the package it lives in, of course.<br><br>Okay, accessing the list of all preferences (requirement 2, from my<br>list) could be done by enumerating all the methods in the system which<br>are in a 'preferences' category, or something like that.<br></blockquote><div><br></div><div>Um, no. Enumerating all classes and looking for methods with the relevant pragma(s), yes.</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">Protocols is something that's part of Smalltalk forever, we should<br>leverage it more. We could bring more power to the system with some<br>simple toolage over of our "protocols" that can browse such<br>programmatic usages..<br></blockquote><div><br></div><div>Dangerous. Smalltalk/V doesn't have them. They're not in the ANSI standard. I've used them and like the power, but they can be like perform on constructed strings, non-obvious.</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">The current pragma approach with class-vars makes it impossible to<br>meet the basic requirements at all.<br></blockquote><div><br></div><div>No it does not.</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">It also takes our deployment image from being a pure-and-simple,<br>traditional Smalltalk -- of just classes, objects and messages -- and<br>tacks on a new computery whiz-bang concept called a Pragma. Now, a<br>lot of users' eyes are gonna glaze over. They're done. Their hope<br>that Squeak was an empowering application tool-kit for non-nerds has<br>been quashed. It's in-the-weeds programming afterall. :(<br></blockquote><div><br></div><div>Um, pragmas are in the base system for things like unwind-protect and primitives. The syntax has been there since Smalltalk-80 (or even 76?). Message has been there from the get-go. Pragmas are proving themselves useful in many contexts. They can no longer be considered whizz-bang magic. We use them a lot. They're nice exactly because one mechanism has general uses, unlike, for example, the Preferences framework, which ties code to a clumsy "wrapping of a dictionary", instead of allowing code to express itself as it chooses, and identify its choices to external tools to operate upn it only when desirable..</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"><span class="gmail-">> But to achieve<br>> this elegance the pragma scheme must be thought through; for example<br>> extending the Preference system to allow preferences to be set without<br>> needing preference setter methods (and maybe even modifying the compiler to<br>> declare variables in pragma preference methods as class vars?).<br><br></span>It's just a wrapped Dictionary! Isn't it?<br></blockquote><div><br></div><div>No. Not at all. A Dictionary may be a useful thing to present in response to 2. but other than that its implementation driving design.</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"><br>Friends, IMO, Squeak's potential beyond our little group of developer<br>dudes lies in the how well we can bring the power of the class library<br>to regular, non-programmer *users*. People who don't identify<br>themselves as programmers, but want something more powerful than a<br>spreadsheet. Right now, I believe that's still possible. But I<br>believe designing Squeak around our developer-centric selves,<br>increasing usage of whiz-bang language features will not get us there.<br>IMO the philosophy of staying as simple and traditional and fighting<br>complexity as long as we possibly can, will improve chances of wider<br>adoption.<br></blockquote><div><br></div><div>Um, pragmas are in quite a few Smalltalks now. And I've already defended them against the whizz-bang accusation.</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"><br>IMO, we should just do Smalltalk and objects. 1) Get rid of teh class<br>vars, 2) change the getter/setters to access Preferences<br>wrapped-dictionary, which still compiles dynamic accessors, if<br>necessary, and 3) hopefully also ditch the pragmas in favor of a<br>protocol selection.<br></blockquote><div><br></div><div>Couldn't disagree more :-)</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"><br>Best.<br></blockquote></div><br><div class="gmail_signature"><div dir="ltr"><div><span style="border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 19, 2016 at 10:21 AM, Chris Muller <span dir="ltr"><<a href="mailto:ma.chris.m@gmail.com" target="_blank">ma.chris.m@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>> Gentlemen, may I ask what you thought of my list of requirements?<br>
>><br>
>> <a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2016-March/188486.html" rel="noreferrer" target="_blank">http://lists.squeakfoundation.<wbr>org/pipermail/squeak-dev/2016-<wbr>March/188486.html</a><br>
> IMHO the first point is not a requirement (what?) at all but a solution (how?).<br>
<br>
It depends on who your actor is. I get your point when the<br>
actor is an end user playing with an iPad, but requirement #1 is<br>
trying to assert that the type of actor for *these* requirements is a<br>
non-programmer user who wants to write a little code or make a little<br>
application that might have a Preference or two. In that case, the<br>
requirement is that we have a simple, easy to understand English-based<br>
class hierarchy, and not computery terms.<br>
<br>
We already have it anyway, so we don't even need to discuss this..<br>
<br>
>> I honestly think we don’t need pragmas to do it.<br>
> I agree but I cannot understand why you seem to hate pragmas.<br>
<br>
Whoa, I don't "hate" pragma's at all, they're an important capability,<br>
I'm simply saying that using them for our Preferences system makes a<br>
design that is not only unnecessarily complex and confusing but<br>
embarassingly bad and incapable. We're supposed to be the language of<br>
"objects" but can't even represent a template of Preferences to solve<br>
the most basic of requirements, like #7..!<br>
<br>
Meanwhile, Marcel's new Themeing implementation solves the same<br>
problem with a fraction of the code and complexity, and yet is 10X<br>
more powerful. Its a leveraged design based on objects, instead of<br>
diluted based on dozens of global variables..<br>
<br>
>>> the other<br>
>>> is in being modular, in that the pragma method can live in the package to<br>
>>> which it belongs.<br>
>><br>
>> Let’s not let package concerns dictate the design.<br>
> IMHO packaging concerns are very important design drivers. I consider missing modularity one of the main problems with Smalltalk.<br>
<br>
Don't worry, our packaging system is flexible enough that we don't<br>
need to limit our design because of packaging (a developer activity,<br>
BTW). As I showed earlier in this thread, Pragma preferences provide<br>
no benefit in the area of packaging, every preference accessor can<br>
still be in its own package. The new theming implementation proves<br>
this, too.<br>
<br>
>> snip...<br>
<br>
> I don’t understand why you consider pragma more computery whihz-bang than classes, objects and messages. I’d even say they are much simpler to understand than metaclasses. And pragmas are in all commonly used Smalltalk implementations by now.<br>
<br>
Because they represent metadata about something "in the computer"<br>
rather than a description of the domain which the power-user actor<br>
cares about.<br>
<br>
They're supposed to represent information about methods of the system.<br>
Using them for the user domain models is a confusing mis-use.<br>
<br>
We *really should* try harder to target users besides our developer<br>
selves. Please? Smalltalk was the only system in which users can<br>
learn to program without learning or caring anything about computers.<br>
If they have to become programmers, then suddenly the whole menu of<br>
more popular languages like Python or Ruby becomes just as accessible<br>
to them. We keep trying to nullify our Smalltalk advantage.. :(<br>
<br>
>> IMO, we should just do Smalltalk and objects. 1) Get rid of teh class<br>
>> vars, 2) change the getter/setters to access Preferences<br>
>> wrapped-dictionary, which still compiles dynamic accessors, if<br>
>> necessary, and 3) hopefully also ditch the pragmas in favor of a<br>
>> protocol selection.<br>
> Please no.<br>
<br>
What about requirement #7?<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="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>