On 26 Jul 2014, at 10:03, Marcus Denker <marcus.den...@inria.fr> wrote:
>
> On 26 Jul 2014, at 09:58, stepharo <steph...@free.fr> wrote:
>
>>
>>> Slowly working on it… very early (and right now broken) stage is in the
>>> image.
>>> And it is not yet decided how it will look like exactly… the only thing
>>> clear is
>>> that we need to use
>>>
>>> {#ivar1. #ivar2 . #boolean => BooleanSlot }
>>>
>>> instead of the strings… both for ivars and class vars… I want to finish and
>>> debug the machinery around and then
>>> start to play with it.
>>>
>>> I am a bit tempted to go the “backward compatible” way and not use the term
>>> Slot but something like this:
>>>
>>> TestCase subclass: #RBProgramNodeTest
>>> instanceVariables :{#ivar1. #ivar2 . #boolean => BooleanSlot }
>>> classVariables: {#MyGlobal}
>>> category: 'AST-Tests-Core’
>>>
>>> Ah, and we need to think about “category”… as we now have packages.
>>
>> You see how this is great not to have PoolDict in our face :)
>> I would rename classVariables: into sharedVariables: and make them optional
>> :)
>>
> I actually think shared variables is not good… everyone talks about Class
> Variables
> All Tutorials, all books. And it is very easy to confuse the term with Pools
> (I actually did so
> when looking at the Class Builder).
e.g. we would need to change the whole api… now we have
aClass classVariableNamed: ‘MyClassVar’.
would need to change to
aClass sharedVariableNamed: ‘MyClassVar’.
and then: aren’t Pool imported variables shared? So would this
return a variable from a pool? if not, wouldn’t that be confusing?
Marcus
