Your understanding of the meaning is same as mine. If it's true then user of
Workspace must declare variable, and by same token if the radio button is not
selected then it is expected that they should declare the variable.
So your version below makes sense.
On 06 Jun 2011, at 10:03 PM, Stéphane Ducasse wrote:
Thanks carlo
now reading the code this is even more confusing..
> mustDeclareVariables
to me measn that you should declare var :)
so the correct version is
mustDeclareVariableWording
^ mustDeclareVariables
ifTrue: ['<no> Automatically create variable declaration'
translated]
ifFalse: ['<yes> Automatically create variable declaration'
translated]
but I may be wrong.
Stef
On Jun 6, 2011, at 9:24 PM, Carlo wrote:
> Hi
>
> As far as I can see the behavior is correct. If you declare the variables as
> you have
>>
>>> |persons aPerson|
> then they won't be bound to the Workspace.
> If you do not declare them then these variables should be bound to the
> Workspace.
> You can bring up the Workspace menu and select 'Inspect variables' to see
> what is bound.
>
> I did notice though that there is a boolean logic bug compared to squeak 4.1
> in
> Workspace>>mustDeclareVariableWording
>
> ^ mustDeclareVariables not
> ifTrue: ['<yes> Automatically create variable declaration'
> translated]
> ifFalse: ['<no> Automatically create variable declaration'
> translated]
>
> The 'not' is missing from Pharo1.3 whereas it should be there. This only
> affects the display logic which may confuse users to which mode they are in.
What do you mean?
Because we should have the **same** working (not <>) in both branches since the
info is displayed as a radio button.
if the radio button is on,
it creates variable definiton,
if this is off = no it says it is off (to the creation of variable and not
their non creation) :)
So I guess that my proposal is correct but let us know.
Stef
>
> Carlo
>
> On 06 Jun 2011, at 5:16 PM, Stéphane Ducasse wrote:
>
> Hi miguel
>
> this is probably linked to the way the workspace keeps its binding to declare
> variable.
> Can you check in 1.3 because we will release it soon.
>
> Stef
>
> On Jun 6, 2011, at 4:09 PM, Miguel Sanchez wrote:
>
>> Hi All,
>>
>> I'm not sure if this is a bug or a feature or PEBKAC error.
>>
>> I have strange behaviour In Pharo one click 1.1.1 and 1.2.1, when I open a
>> Shout Workspace and enter the following:
>> ===============================================
>>
>> "Person is a dirty little class that maps from a DB table and a horrible
>> complete creation method."
>>
>> |persons aPerson|
>>
>> aPerson := Person personId: '32055' personTypeId: '1' nationalId:
>> 'I00735' firstName: 'ANA ROSA' surname: 'XXX YYY ZZZ' title: 'Ms' birthday:
>> ('01/01/1970' asDate) language: 'ES ' gender: 'F' maritalStatus: 'M'
>> nationality: 'ES' countryOfResidence: 'IT' activity: 'CN-O' regDate:
>> '17/06/2009 00:00:00' vatRegNo: '1234'.
>>
>> persons := Set new.
>>
>> persons add: aPerson.
>>
>> persons add: 3.
>> ===============================================
>>
>> If I ctrl-d each statement individually. after the final line. persons is a
>> set with the two elements I have just added.
>>
>> If I open a fresh shout workspace, copy and paste the code, select all, and
>> ctrl-d all the text, then I get persons = nil. afterwards.
>>
>> I've debugged and both methods execute in the same way.
>>
>> So like I said, bug, feature or PEBKAC?
>>
>> Thanks,
>>
>>
>> Miguel
>
>
>
>
