Hi Bert,

On Fri, Dec 16, 2016 at 11:50 AM, Bert Freudenberg <bert at freudenbergs.de>
wrote:

> On Fri, Dec 16, 2016 at 11:32 AM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>>
>> Instead of checking for "understands" we should use valueOfFlag: (which
>>> defaults to false) to get back the old behavior. Or we recreate the
>>> preference. Or we make it into a "pragma" preference on some class (which
>>> seems to be the preferred way nowadays, even though it leads to an
>>> explosion of pref accessor methods?)
>>>
>>
>> Well, the current scheme leads to an explosion of preference accessor
>> methods in Preference class.
>>
>
> Well, only because SomeOne™ changed the accessors generator to actually
> put them into the package, when they used to be in their own
> "*autogenerated" package.
>

Ah.  Indeed,  That's the bug.


>
> These accessor methods are only there to speed up the DNU, which is the
> default handler. Maybe on Cog we don't even need the precompiled accessors.
>

While MNU is much faster in contexts like proxies on Cog, its not going to
speed up occasional use.  However, in a tight loop it does help.


>
>
>>   I think the pragma style is far more preferable to this.
>>
>
> I think pragmas are good for finding preference declarations.
>

We're in agreement.  The pragma approach has two main advantages; one it to
identify and allow documenting methods that provide preferences, the other
is in being modular, in that the pragma method can live in the package to
which it belongs.


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


At least one doesn't have the System package being marked as dirty just
>> because preferences have been accessed.
>>
>
> See above - that's a bug IMHO.
>

+1


> I agree that a default MNU that answers false, and doesn't create an
>> accessor method, is a good default.  Although it does suffer the
>> disadvantage that a misspelled reference will simply go unnoticed,
>> defaulting to false.
>>
>
> True. Maybe in a dev image it indeed should raise an exception.
>
> Btw, this is a good discussion :)
>

+1

- Bert -
>

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20161216/4eb4f42a/attachment.html>