[squeak-dev] The Trunk: MorphicExtras-cmm.201.mcz

Levente Uzonyi leves at caesar.elte.hu
Mon Dec 19 19:09:40 UTC 2016


This is something I had written before the discussion started up, but I 
decided to postpone it.

Pragma preferences are way older than the list of "minimum requirements" 
you linked. Seven years ago the goal was to get rid of the central 
collection of preferences and replace it with distributed pragma 
preferences.

About the list:

>  1)  it must have a first-class model (which it already does)
>     Preferences and Preference.  All of the following requirements must be
>     able to be satisfied by talking strictly to this model, (no required
>     browsers or sends to outside classes) with uniform API usage
>     regardless whether the underlying implementation (Pragma or
>     otherwise).

This is more like a request than a requirement. Also, just because 
Preferences still exists, it doesn't mean it should be part of the model.

(Why do I say this? Because you use "must", while I don't think we "must" 
do these; we could do things differently. Perhaps I just haven't found 
yet why we must do it this way.)

>  3)  Ability to access any single Preference object by its Symbolic
>    name.  (We want to maintain the standard Smalltalk "senders" being
>    able to easily find users of preferences by their name).

Does it mean that two external packages cannot use the same name for 
their own preferences? If yes, what will happen if they do?

> 5)  Ability to reset any Preference to its default value, another
>     fixed value, or cycle from its current value to its next value.

What's the next value of the current "Update URL" preference?

Also, 8 makes no sense if external packages can add new preferences, which 
is a must. And 10 depends on 9, so 9 can't be "nice-to-have".


Levente

On Sat, 17 Dec 2016, Chris Muller wrote:

> Well, the pragmas ARE the second way of doing preferences, and so
> let's go back and finish *original* pure-objects implementation,
> rather than continuing down this 2nd way, a long detour which is
> knowingly unfit for the requirements.
>
> If you continue to the end of my email, I assert that the known
> deficiencies with pragmas is their very existence, because they bring
> an unneessary blemish of complexity into the system, and so the only
> way to "fix" that is to remove them.
>
> On Sat, Dec 17, 2016 at 6:13 PM, David T. Lewis <lewis at mail.msen.com> wrote:
>> Hi Chris,
>>
>> On Sat, Dec 17, 2016 at 04:25:10PM -0600, Chris Muller wrote:
>>> 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.
>>>
>>
>> I have no strong preference one way or the other ;-)
>>
>> Having said that, I think that having two kinds of preference is already
>> one too many. So my only strong opinion here is that we should not start
>> another design and implementation until we finish implementing one of the
>> existing ones. If we are moving to pragma preferences, then let's finish
>> doing that. If there are known deficiencies or bugs in the pragma preference
>> implementation, then let's fix them if we know how to do so.
>>
>> I am not saying that I am an advocate of using or not using pragmas, I am
>> just saying that sometimes it is more important to get things done than
>> to get them perfect.
>>
>> Dave
>>
>>
>>> > 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.
>>>
>>


More information about the Squeak-dev mailing list