On 5/20/2010 5:05 PM, Igor Stasenko wrote:
> On 20 May 2010 20:08, Andreas Raab<andreas.raab at gmx.de>  wrote:
>> I think that's the wrong way to deal with the problem. A polymorphic
>> implementation via Project works much better, i.e.,
>>
>> Object>>currentWorld
>>         ^Project current world
>>
> unless you wanna get rid of Project as well.. then you still have to write
> (Smalltalk at: #Project ) blahblahblah
>
> because Smalltalk, is the only global, which i am sure will stay with
> us forever :)

What about removing #currentWorld instead? It seems to me that there's a 
boundary somewhere - if you're assuming "some" UI but not necessarily 
Morphic, it seems that vectoring it through Project current is the right 
approach. If you're assuming "no UI" and consequently, no class Project, 
it seems that at this point #currentWorld might have to go too.

So I'd say, make Object>>currentWorld vector through Project current, 
based on the assumption that some UI will be there, and bundle 
Object>>currentWorld with Project so that if you unload one, you unload 
the other as well. That seems like a nice clean separation of concerns.

>> And the same applies. The pattern should be "Project current display".
>>
> Indeed. Except that i'm not really happy with naming.
> Using a Project  as a name is a bit counterintuitive.

I quite like the name. A "Project" generally context of some sorts; 
having it be the working context of your environment with windows, 
display, sensor, etc. makes sense to me.

> Why it has to be responsible for answering an instance of Display
> or morphic world?

Err ... because we defined it to be that way? ;-)

> I know, it is historically been so, but i wonder if there other (more
> appropriate) dispathes.
>
> Smalltalk graphics display
> Smalltalk ui morphicWorld

I'll object to those two because they don't imply the presence of 
multiple displays or worlds. "Graphics" and "UI" sound like singletons 
to me; "projects" on the other hand can be many.

Cheers,
   - Andreas