On 27 May 2010 06:13, David T. Lewis <lewis at mail.msen.com> wrote:
> On Thu, May 20, 2010 at 08:08:34PM -0700, Andreas Raab wrote:
>> On 5/20/2010 5:05 PM, Igor Stasenko wrote:
>>
>> >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.
>
> I like Igor's suggestion here. To me, the phrases "Smalltalk graphics"
> and "Smalltalk ui" do imply multiple displays or worlds. And the
> expressions are easily evaluated to figure out what objects they
> actually point to.
>
> Vectoring things through Project is an excellent mechanism, but I also
> like the phrases that Igor proposes as a way to express the meaning,
> and as a way to permit the mechanism to be evolved in the future.
>
> As an example, the expression "Smalltalk os windowSystemName" is
> a phrase that is easy to understand, answering the name of the window
> system for the host operating system. The mechanism is totally bogus
> ("Smalltalk os" answers a SmalltalkImage rather than some object
> that represents the host operating system), but it suggests how
> the implementation might look in the future (a class that represents
> the host OS). Thus the phrase expresses intent rather than mechanism,
> and I think this is a good thing.
>

The difference between:

Smalltalk ui browser fullOnClass: #MyClass

and:

SystemBrowser default fullOnClass: #MyClass

is in following:
The #ui message defines a UI module as a whole, which you want to speak with.
While various concrete classes, actually just defining a various subsets of UI.

And so, when your system having no any ui,
you could just throw an error at #ui message, without proceeding further.

So, we could have only a single stub for all ui operations.
Now, think how many stubs you will need to implement to make the whole
UI [un]loadable
at user's will, when your code is allowed to speak with concrete
classes directly.

In same way, 'Smalltalk graphics' defines an intent to talk with
'graphics' module.
Sure thing, it doesn't implies that there are only one display or
world (this is maybe unclear from an example which i shown).

So, my vision is, that Smalltalk should serve as _the only_ hub to
reach various modules, installed in system.

So, then we could implement:

Smalltalk ui unload.

and from that point, sending any messages to (Smalltalk ui), except
from #isLoaded (and maybe some other userful ones - like #load) will
lead to error.


> Dave
>


-- 
Best regards,
Igor Stasenko AKA sig.