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

It depends on who your actor is.  I get your point when the
actor is an end user playing with an iPad, but requirement #1 is
trying to assert that the type of actor for *these* requirements is a
non-programmer user who wants to write a little code or make a little
application that might have a Preference or two.  In that case, the
requirement is that we have a simple, easy to understand English-based
class hierarchy, and not computery terms.

We already have it anyway, so we don't even need to discuss this..

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

Whoa, I don't "hate" pragma's at all, they're an important capability,
I'm simply saying that using them for our Preferences system makes a
design that is not only unnecessarily complex and confusing but
embarassingly bad and incapable.  We're supposed to be the language of
"objects" but can't even represent a template of Preferences to solve
the most basic of requirements, like #7..!

Meanwhile, Marcel's new Themeing implementation solves the same
problem with a fraction of the code and complexity, and yet is 10X
more powerful.  Its a leveraged design based on objects, instead of
diluted based on dozens of global variables..

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

Don't worry, our packaging system is flexible enough that we don't
need to limit our design because of packaging (a developer activity,
BTW).  As I showed earlier in this thread, Pragma preferences provide
no benefit in the area of packaging, every preference accessor can
still be in its own package.  The new theming implementation proves
this, too.

>> snip...

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

Because they represent metadata about something "in the computer"
rather than a description of the domain which the power-user actor
cares about.

They're supposed to represent information about methods of the system.
Using them for the user domain models is a confusing mis-use.

We *really should* try harder to target users besides our developer
selves.  Please?  Smalltalk was the only system in which users can
learn to program without learning or caring anything about computers.
If they have to become programmers, then suddenly the whole menu of
more popular languages like Python or Ruby becomes just as accessible
to them.  We keep trying to nullify our Smalltalk advantage..  :(

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

What about requirement #7?