The Trunk: MorphicExtras-cmm.201.mcz

>
>
> On Wed, Dec 7, 2016 at 11:06 AM, <[hidden email]> wrote:
>>
>> Chris Muller uploaded a new version of MorphicExtras to project The Trunk:
>> http://source.squeak.org/trunk/MorphicExtras-cmm.201.mcz
>>
>>
>> +       ((Preferences canUnderstand: #useBiggerPaintingBox) and: [
>> Preferences useBiggerPaintingBox ]) ifTrue: [left := left  - (( self width *
>> 1.5)- self width)].
>> -       Preferences useBiggerPaintingBox ifTrue: [left := left  - (( self
>> width
>
>
>
> Why did we remove Preferences class>>doesNotUnderstand:?
>
> - Bert -
>
>
>
>

> On Tue, Dec 13, 2016 at 11:52 AM, Chris Muller <[hidden email]> wrote:
>>
>> > Instead of checking for "understands" we should use valueOfFlag: (which
>> > defaults to false) to get back the old behavior.
>>
>> Hmm, I'm not sure "false" makes sense as a universal default value.
>
>
> False is the default for valueOfFlag:. It is nil for valueOfPreference:.
>
>>
>> Apps typically choose their own lazy-initialized values
>> attribute-by-attribute, and usually based on it having been nil.
>
>
> We're talking about old-style preferences which IMHO used to be a very
> convenient, succinct, and highly readable. We just wrote "Preferences myFlag
> ifTrue: [...]" and this would universally work *without any other support
> code*. This was really nice for live experimenting, you just throw this
> expression in somewhere without having to worry about breaking anything.

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

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

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

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

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

> Am 18.12.2016 um 01:13 schrieb David T. Lewis <[hidden email]>:
> 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.

> 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 <[hidden email]> 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.
>>>
>>