Hi Chris,

See my answers below.

> Am 17.12.2016 um 23:25 schrieb Chris Muller <asqueaker at gmail.com>:
> 
> 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?).

> I honestly think we don’t need pragmas to do it.
I agree but I cannot understand why you seem to hate pragmas.

>> 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. 

>  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.
> 
>>> 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.
>> 
>> 
>> 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
>> 
>>    ^Var ifNil: [Var := true/false/aSymbol]
> 
> 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.
> 
>> 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.
>> 
>>> Having actual Preference objects managed by a Preferences class takes care
>>> of all of that, once and for all.
>> 
>> 
>> 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.
> 
> 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
But, but, but… IMO that is much, much more complicated than pragma preferences. And it adds a lot of duplication, no?
> 
> #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.
> 
> 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..
> 
> The current pragma approach with class-vars makes it impossible to
> meet the basic requirements at all.
> 
> 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.   :(
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.

> 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?
> 
> 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.
Every time I look at the old Preference implementation I get lost in its complexity. Whereas the pragma style preferences are super simple. One class (instance) variable and two accessors.

> 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.

> Best.
Cheers,
Bernhard