[squeak-dev] [ANN] Preference pragmas

Igor Stasenko siguctua at gmail.com
Thu Mar 5 00:37:36 UTC 2009


2009/3/5 Bert Freudenberg <bert at freudenbergs.de>:
> - Show quoted text -
> On 05.03.2009, at 00:34, Michael Rueger wrote:
>
>> Andreas Raab wrote:
>>>
>>> Folks -
>>> I wanted to make the property whether to show individual processes in
>>> MessageTally a preference and couldn't recall any of the three gazillion
>>> methods to create one ;-) So I decided enough is enough and added the
>>> ability to register a preference via Pragma. In other words, you specify two
>>> class side accessors (using MessageTally as example):
>>> showProcesses
>>>   "Indicates whether to show each process separately or cumulatively."
>>>   <preference: 'Show Processes in MessageTally'
>>>       category: 'debug'
>>>       balloonHelp: 'If enabled, each profiled process is shown
>>> individually in MessageTally'
>>>       type: #Boolean>
>>>   ^ShowProcesses
>>
>> Looking at your version I see you made some slightly different design
>> choices than in the design that has been in design discussion and worked on
>> in the last couple of weeks on the Pharo list.
>>
>> Can you elaborate what motivated the different design? Meaning what parts
>> of the Pharo version could be made better? Or, sorry for basically asking
>> the same thing three times, what would it take to adopt the Pharo version
>> for Squeak?
>
>
> Hmm, at least I am not aware of what is going on in Pharoland. I'm reluctant
> to subscribe to the Pharo list. Not because I'm not interested, but because
> for one my spare time is already filled up by Etoys+Squeak+OLPC+Sugar, and
> also because the Pharo creators went to their own playground specifically to
> get away from certain opinions on squeak-dev. I feel like I shouldn't haunt
> them uninvitedly.
>
> I wonder if someone could summarize what's going on on the greener side,
> like the weekly excerpts we sometimes get for squeak-dev ... or is there
> such a thing for Pharo already?
>
> Anyway, I think it's great you point out this existing design. Duplication
> of effort is not something we should put up with in our small community. Do
> you have a direct pointer to the code in question?
>

Well, it can be seen at different angle  - a competition. If so, then
this is good as well - both vendors will try best to make own
framework better than others :)
And of course, if they decide to join efforts, both will win.

> - Bert -
>


-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list