Gentlemen, may I ask what you thought of my list of requirements?

   http://lists.squeakfoundation.org/pipermail/squeak-dev/2016-March/188486.html

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.

> We're in agreement.  The pragma approach has two main advantages; one it to
> identify and allow documenting methods that provide preferences,

I honestly think we don't need pragmas to do it.

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

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

#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.   :(

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

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.

Best.