Preferences revamp redux
Locked
 
|
>> Gentlemen, may I ask what you thought of my list of requirements?
>> >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2016-March/188486.html > IMHO the first point is not a requirement (what?) at all but a solution (how?). It depends on who your actor is. I get your point when the actor is an end user playing with an iPad, but requirement #1 is trying to assert that the type of actor for *these* requirements is a non-programmer user who wants to write a little code or make a little application that might have a Preference or two. In that case, the requirement is that we have a simple, easy to understand English-based class hierarchy, and not computery terms. We already have it anyway, so we don't even need to discuss this.. >> I honestly think we don’t need pragmas to do it. > I agree but I cannot understand why you seem to hate pragmas. Whoa, I don't "hate" pragma's at all, they're an important capability, I'm simply saying that using them for our Preferences system makes a design that is not only unnecessarily complex and confusing but embarassingly bad and incapable. We're supposed to be the language of "objects" but can't even represent a template of Preferences to solve the most basic of requirements, like #7..! Meanwhile, Marcel's new Themeing implementation solves the same problem with a fraction of the code and complexity, and yet is 10X more powerful. Its a leveraged design based on objects, instead of diluted based on dozens of global variables.. >>> the other >>> is in being modular, in that the pragma method can live in the package to >>> which it belongs. >> >> Let’s not let package concerns dictate the design. > IMHO packaging concerns are very important design drivers. I consider missing modularity one of the main problems with Smalltalk. Don't worry, our packaging system is flexible enough that we don't need to limit our design because of packaging (a developer activity, BTW). As I showed earlier in this thread, Pragma preferences provide no benefit in the area of packaging, every preference accessor can still be in its own package. The new theming implementation proves this, too. >> snip... > 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. Because they represent metadata about something "in the computer" rather than a description of the domain which the power-user actor cares about. They're supposed to represent information about methods of the system. Using them for the user domain models is a confusing mis-use. We *really should* try harder to target users besides our developer selves. Please? Smalltalk was the only system in which users can learn to program without learning or caring anything about computers. If they have to become programmers, then suddenly the whole menu of more popular languages like Python or Ruby becomes just as accessible to them. We keep trying to nullify our Smalltalk advantage.. :( >> IMO, we should just do Smalltalk and objects. 1) Get rid of teh class >> vars, 2) change the getter/setters to access Preferences >> wrapped-dictionary, which still compiles dynamic accessors, if >> necessary, and 3) hopefully also ditch the pragmas in favor of a >> protocol selection. > Please no. What about requirement #7? |
|
|
Hi All, replying to an earlier message now we have a good subject line :-) On Sat, Dec 17, 2016 at 2:25 PM, Chris Muller <[hidden email]> wrote: Gentlemen, may I ask what you thought of my list of requirements? I like some of them. To be specific... 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 - informs the user of the set of available preferences and documents them - provides a convenient UI for setting them 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: - the application can continue to work if Preferences is unloaded - the application does not have to restrict itself to the Preferences style and can use something it finds convenient 2. very useful; can easily be derived from pragma preferences 3. Not sure symbolic names are useful. A user readable name is useful, but an additional symbolic name is just cruft 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) 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. 6. Sure. Again something that can be done with pragma preferences 7. Sure. Can be constructed from 2. 4. and ability to access current value. 7.5, 7.6 why? Don't see any pressing need for these. Seem to be forcing a Dictionary implementation. 8. Sure. Again a preference saving/loading mechanism is not antithetical to pragma preferences. 9. Sure 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. These were derived through careful consideration of the real-world use 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. > We're in agreement. The pragma approach has two main advantages; one it to I was agreeing with Bert, not you. You and I clearly disagree. > the other 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. >> But having to implement preference storage over and over again is not the 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 - states that this is a system preference - documents its purpose - identifies it to tools that want to collect the set of system preferences - etc > So with this approach and help from the Preferences framework one should be As others have said the above is way more complex than a pragma preference. It also ties the application to the Preference UI.
Um, no. Enumerating all classes and looking for methods with the relevant pragma(s), yes. Protocols is something that's part of Smalltalk forever, we should 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. The current pragma approach with class-vars makes it impossible to No it does not. It also takes our deployment image from being a pure-and-simple, 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.. > But to achieve 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.
Um, pragmas are in quite a few Smalltalks now. And I've already defended them against the whizz-bang accusation.
Couldn't disagree more :-)
_,,,^..^,,,_ best, Eliot On Mon, Dec 19, 2016 at 10:21 AM, Chris Muller <[hidden email]> wrote: >> Gentlemen, may I ask what you thought of my list of requirements? _,,,^..^,,,_ best, Eliot |
|
|
Hi All,
from Chris's requirement #4, 4) Ability to ask any Preference its default value, without resetting its current value, here's some simple code for extracting the default value from a pragma preference method, if it specifies a literal default value. The three styles of providing defaults in pragma preferences are essentially ^ClassVar ifNil: [#someDefaultLiteral] ^ClassVar ifNil: [ClassVar := #someDefaultLiteral] anything else (and we'll see all of these soon). Looking at the byte codes for the first two forms we see 21 <40> pushLit: ThoroughSenders 22 <88> dup 23 <73> pushConstant: nil 24 <C6> send: == 25 <99> jumpFalse: 28 26 <87> pop 27 <71> pushConstant: true 28 <7C> returnTop and 21 <40> pushLit: ShowSugarNavigator 22 <88> dup 23 <73> pushConstant: nil 24 <C6> send: == 25 <9B> jumpFalse: 30 26 <87> pop 27 <72> pushConstant: false 28 <81 C0> storeIntoLit: ShowSugarNavigator 30 <7C> returnTop CompiledMethod provides abstractBytecodeMessagesDo: to enumerate over the byte codes independently of the byte code set's encoding. So this extracts the default value from one of the two above: | literal | self abstractBytecodeMessagesDo: [:msg| msg selector == #pushConstant: ifTrue: [literal := msg argument] ifFalse: [msg selector == #methodReturnTop ifTrue: [^literal]. msg selector ~~ #storeIntoLiteralVariable: ifTrue: [literal := nil]]]. literal It works by identifying any literal via "msg selector == #pushConstant:" and stores it in literal. Then if it sees anything other than #methodReturnTop or #storeIntoLiteralVariable: it nils the literal. And it returns the value of literal as soon as it sees #methodReturnTop. So the following browses all the pragma preferences in the system that don't fit the first two pattens: self systemNavigation browseAllSelect: [:m| (m pragmaAt: #preference:category:description:type:) notNil and: [| literal | m abstractBytecodeMessagesDo: [:msg| msg selector == #pushConstant: ifTrue: [literal := msg argument] ifFalse: [(msg selector ~~ #methodReturnTop and: [msg selector ~~ #storeIntoLiteralVariable:]) ifTrue: [literal := nil]]]. literal isNil]] Of 121 pragma preference methods in my system 22 don't fit the pattern. Some are project-specific preferences that defer to Project's own custom preference framework, which is necessary to allow individual projects to have their individual preferences (something that the dictionary of preferences framework also cannot handle without special accommodation). Some are bad examples: booleanPref <preference: 'Boolean Preference Example' category: 'Examples' description: 'A simple example for a boolean preference (see PreferenceExample>>booleanPref)' type: #Boolean> ^BooleanPref Some are richer: activeColor <preference: 'Corner Grip highlight color' category: 'colors' description: 'The highlight-color of window corners' type: #Color> ^(self activeForm colorAt: 24@24) alpha: 1 But I hope you get the point that with very little machinery we can extract the default value in a substantial majority of cases. Since we'd also like to get rid of the setter it would be good to be able to extract the class variable so it can be set simply by sending it #value: , so... allow me to add abstractBytecodeMessages, then something similar to the following (*) (((method abstractBytecodeMessages first: 5) collect: [:ea| ea selector]) hasEqualElements: #(#pushLiteralVariable: #doDup #pushConstant: #send:super:numArgs: #jump:if:)) ifTrue: [^(method abstractBytecodeMessageAt: method initialPC) argument] answers the class variable, allowing the Preference UI to - derive its current value - reset its value given the default extracted above (*) one could insist on the send being of #== and the pushConstant: supplying nil. So with these two pieces of machinery in the Preferences UI we don't need setter methods for pragma preferences at all. Note that none of the bytecode magic has to be visible to the author of a pragma preference, but i does have to be understood by the maintainer of the Preference UI. HTH _,,,^..^,,,_ best, Eliot |
|
|
In reply to this post by Eliot Miranda-2
Hi Eliot,
> 1. I see no need for Preferences except as a UI tool. I do. Most definitely. You're an expert VM developer. I'm one of your customers wanting to applications which can use it, but currently, can't. > Preferences are used > to control parts of the system that can have useful alternative behaviors. > Having a Preferences UI is useful as it > - informs the user of the set of available preferences and documents them > - provides a convenient UI for setting them > 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: > - the application can continue to work if Preferences is unloaded A "Preference" can relate to anything. Users want to be able to "prefer" certain aspects even at the Kernel level. They're as universally relevant as Collections. So the Preferences domain capability (NOT the UI) should be assumed to be part of the core set of packages (Kernel, Collections, et al). The Preferences model is just two simple classes. There is not a lot to be gained by unloading them, even on a Raspberry pi. > - the application does not have to restrict itself to the Preferences style > and can use something it finds convenient An application already does not have to restrict itself (unless they want to commit to your byte-code-analyzing solution), but I think they should have the option to participate in a capable and understandable Preferences system provided by Squeak that lets them reap the capabilities described by these requirements. > 2. very useful; can easily be derived from pragma preferences Its very useful, but no one did it because its _not_ so easy for anyone other than Smalltalk expert developers. Unfortunately, they're too busy developing awesome VM's and stuff.. ;) > 3. Not sure symbolic names are useful. A user readable name is useful, but > an additional symbolic name is just cruft I want to be able to #perform: them. > 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) No one will engage in doing such a derivation before asking themselves, "why am I doing this instead of just rolling my own object?" > 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. No one said anything about restricting anything. This is just a convenience extension, not very important, but instead of only having [true | false] it would be nice to if the user could cycle through things like: [small | medium | large] [trunk | inbox | squeak51] Again, only for UI pre-population convenience, it does NOT imply any sort of restriction from the user entering their own URL whatsoever. Okay? > 6. Sure. Again something that can be done with pragma preferences > 7. Sure. Can be constructed from 2. 4. and ability to access current value. "Can" be. 'Nuff said... Does it strike you how many of your solutions require you to scan the system, collect up the preferences into temporary collections, again and again? Like a relational database application. The object solution demonstrated by UserInterfaceTheme did not have to sacrifice any of your packaging requirements, yet already easily solves this requirement and more. > 7.5, 7.6 why? Don't see any pressing need for these. Seem to be forcing a > Dictionary implementation. To support ReleaseBuilder. It does not force a Dictionary implementation. > 8. Sure. Again a preference saving/loading mechanism is not antithetical > to pragma preferences. Eliot, I'm sorry, but storing preference values in a bunch of global variables scattered all throughout the system IS antithetical to saving/loading entire sets of preferences... > 9. Sure But we can't do it! I want the ability to adjust all my #fontPreferences independently of my #colorPreferernces independently of my #desktopBackground independently of my #systemPreferences. As a user, I cannot begin to use Squeak's preferernce system to do this. Nor could the new Theming introduced in 5.1, which is why we rolled our own -- UserInterfaceTheme, even though it solves the same basic problem described by these requirements. There is no dynamic model available in the Pragma prefs, only static values encoded in CompiledMethods. Another requirement is, the ability to *override* preferences in more-specific contexts (like previewing a theme), but "fall back" to the more global one if a for the preference value which were not overridden. Static Pragma prefs have no ability to do this. > 10. That's what pragma preferences do. That's one of the major advantages > of pragmas in general. This can be done anyway. Its not an "advantage" of Pragma's at all, as demonstrated by the new Themeing. > 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. An object can do the same. Code doesn't need to be labelled, a preference value merely needs to be associated, from code within its own package. We can meet your packaging needs with objects, if only you're willing to consider Preferences a universal (kernel) thing. >> These were derived through careful consideration of the real-world use >> cases, both for Squeak and external applications. They are open for >> discussion, of course! >> >> We don't need a special language feature to provide a simple and >> elegant wrapping of a Dictionary. We just need to get back to >> Smalltalk and objects. > > > 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. I can have one Dictionary representing only the "presentation-mode" preferences, another Dictionary small-screen preferences, and I can diff the two, very easily. I can apply them without affecting my other system preferences. Introducing Collections (Dictionary's?) into our model lets us encapsulate just the changes to a Squeak system (e.g. presentation mode ON, or OFF). Substitute (dark) and (light) above, (beginner) and (expert), etc. with any other subset. Then we can compare them, apply them, save them, etc. independently of others in the system. When are scattered about in global variables, we solved our packaging concern, but blew up the domain flexibility. I want to have our cake and eat it too. No regular user will try to scrape information from CompiledMethods when they could just roll their own Dictionary. >> > the other >> > is in being modular, in that the pragma method can live in the package >> > to >> > which it belongs. >> >> Let's not let package concerns dictate the design. Let's make the >> right design for users, *then* optimize out any packaging issues that >> may arise. There's no reason Preference accessors can't just as >> easily live in the package they belong without needing to use pragma's >> and class-vars. > > > This is not about Monticello packages. It is about complex systems being > composed of components. Scattering them into global vars is the opposite of 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. The UI, yes. But your app still must access its preferred values, and Preference and Preferences is just two classes, so what is the problem? >> That's what I thought too, and why I originally argued against >> answering arbitrary default value of false, before agreeing, but then >> someone mentioned that the developer could have easily misspelled it, >> causing a hidden bug. I couldn't agree more, and that seems like it >> really dilutes any net gain for the user. Its complex and magic, >> instead of just simple. > > > 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 > - states that this is a system preference > - documents its purpose > - identifies it to tools that want to collect the set of system preferences > - etc Eliot, when we talk to new users about how Smalltalk works, they learn that objects must be able to understand the messages they send. Taht's the 99% case, right? So having this in a part of the system which should be at the *user-level*: Preferences someMispelledPreferenceName silently answer "false", I'm sorry but, to them, its magic. Its also a nightmare for debugging even for experienced developers, and totally unnecessary in a lifecycle that involves testing. >> A pure-Smalltalk pattern can do it. If we want to co-locate access >> and the default value in a lazy accessor like this. >> >> somePreference >> ^ (Preferences somePreference ifNil: >> [ Preferences >> addPreferenceNamed: #somePreference >> description: 'When true it means...' >> default: theDefaultValueForSomePreference ]) value > > > As others have said the above is way more complex than a pragma preference. Who said anything about the above? I'll have to go back and look.. Using a meta-level langauge concept to represent the user domain unnecessarily is more complex than simply using the regular objects. > It also ties the application to the Preference UI. You used this as the basis of several of your arguments, but it does NOT tie it to the Preference UI. It ties it to the Preferences class, which is a kernel-level concept. >> #somePreference resides in the package it lives in, of course. >> >> Okay, accessing the list of all preferences (requirement 2, from my >> list) could be done by enumerating all the methods in the system which >> are in a 'preferences' category, or something like that. > > Um, no. Enumerating all classes and looking for methods with the relevant > pragma(s), yes. Whether we do this with existing infrastrucutre (protocols) or pragmas is less important that the global-variable storage, because that's the source of the inability to repsent preferences in a usable object model. >> Protocols is something that's part of Smalltalk forever, we should >> leverage it more. We could bring more power to the system with some >> simple toolage over of our "protocols" that can browse such >> programmatic usages.. > > Dangerous. Smalltalk/V doesn't have them. They're not in the ANSI > standard. No problem, even if Smalltalk/V wanted to adopt Squeak's preference system, they wouldn't be able to without some manual porting effort anyway. They can change to use Pragma's or something else.. > I've used them and like the power, but they can be like perform > on constructed strings, non-obvious. They're something that regular and beginning users are exposed to. By contrast, parsing bytecodes, hiding setters, etc., -- are much less obvious. I suggested some toolage. Anyway, Eliot, you've been developing a VM for the last years, I wish you would trust me with my app ideas and user-level interaction needs. I've put a LOT of thought into them.. >> The current pragma approach with class-vars makes it impossible to >> meet the basic requirements at all. > > > No it does not. Well, I actually need the ability to compare ANY two sets of Preferences, not just the current settings with the default settings. You only solved #7 by parsing bytecodes to extract out the default value (which is insane!). I need to diff ANY two instances, save/load them, and arrange them into a hierarchy of overridden prefs. All of those things can be done with UserInterfaceTheme. NONE of those things can be done with Pragma prefs. >> It also takes our deployment image from being a pure-and-simple, >> traditional Smalltalk -- of just classes, objects and messages -- and >> tacks on a new computery whiz-bang concept called a Pragma. Now, a >> lot of users' eyes are gonna glaze over. They're done. Their hope >> that Squeak was an empowering application tool-kit for non-nerds has >> been quashed. It's in-the-weeds programming afterall. :( > > > 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. Agree, I simply meant (mis)using them to do Preferences. A said (mis) because Pragma's are meant to provide meta-descriptions, not represent part of the user's domain model. > 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.. Instead of saying "clumsy" I wish you would say one single requirement that cannot be met by my proposal. I have done that against Pragma's, but you came up with a "solution" which involved analyzing bytecodes, which, IIUC, wouldn't solve the requirement of comparing against other than the default value. >> > 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?). >> >> It's just a wrapped Dictionary! Isn't it? > > > 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. I meant to say a "dictionary" not Dictionary. The *concept* of a collection of key->value associations. I started with requirements and ended up thinking about a Dictionary for implementation. You started with Pragma's as the "solution" and then convinced yourself it was the only solution to the problem of packaging. It's not. >> Friends, IMO, Squeak's potential beyond our little group of developer >> dudes lies in the how well we can bring the power of the class library >> to regular, non-programmer *users*. People who don't identify >> themselves as programmers, but want something more powerful than a >> spreadsheet. Right now, I believe that's still possible. But I >> believe designing Squeak around our developer-centric selves, >> increasing usage of whiz-bang language features will not get us there. >> IMO the philosophy of staying as simple and traditional and fighting >> complexity as long as we possibly can, will improve chances of wider >> adoption. > > Um, pragmas are in quite a few Smalltalks now. And I've already defended > them against the whizz-bang accusation. As long as we keep ignoring regular users, they will keep ignoring Squeak. >> IMO, we should just do Smalltalk and objects. 1) Get rid of teh class >> vars, 2) change the getter/setters to access Preferences >> wrapped-dictionary, which still compiles dynamic accessors, if >> necessary, and 3) hopefully also ditch the pragmas in favor of a >> protocol selection. > > > Couldn't disagree more :-) Well, I simply can't use it. No one other than expert developers will either, until they need something more application-robust, at which point they'll probably just roll-their-own.. :( |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |