[squeak-dev] Re: Pragmas (Re: The Inbox: Morphic-phite.429.mcz)

Igor Stasenko siguctua at gmail.com
Tue Apr 27 00:13:52 UTC 2010

On 27 April 2010 02:45, Igor Stasenko <siguctua at gmail.com> wrote:
> On 27 April 2010 02:11, Andreas Raab <andreas.raab at gmx.de> wrote:
>> I find the annotation-based discovery superior to hardcoded
>> references to classes and registries that may not exist in this form in the
>> future.
> +1

However, i'd like to add, that indirect forms of declarations (like
pragma annotations) is not always sufficient,
because it makes impossible a direct communication between services,
and thus having a limited potential.

The code example like following:

MenuEntrySpec newFrom: (Dictionary newFromPairs: #(
               contents 'Well... hello?'
               help 'Displays the Hello World'
               location ('Help')
               target MenuMorph selector inform: arguments ('Hello World!')
               position first))

introducing a rigid factors, because of use of globals (here -
MenuEntrySpec and MenuMorph).

In contrast, if we turn it into a set of declarations like this

<createDockingBarMenuWithPriority: 50>
<fillDockingBarMenu: #extras priority: 20>

is just an annotations, which not quite informal, since there is no
usual sender-implementor chain and no direct communication,
which can be tracked, debugged. You should implement a separate
discovery mechanism, which searching for these annotations
and controls the menu creation & its properties.
Also, there is no any guarantee, that these annotations will be taken
into account by system, while obviously a package author expects from
a system to react on them and act accordingly.

So, we could have our cake and eating it too:
- do not use globals (like MenuEntrySpec). Really, a format (or class)
which is used for holding a menu spec is totally irrelevant to an
external package. So, why external package should care about these
details, why not like following:

  ^ World menuRegistry "whatever"

MyExternalPackageClass class>>initialize
  self addMenuEntry.

MyExternalPackageClass class>>addMenuEntry

   self globalMenuRegistry addMenuEntry: #(
       contents 'Well... hello?'
                help 'Displays the Hello World'
                location ('Help')
                target selector #inform: arguments ('Hello World!')
                position first)
      forClass: self

So, as simple as that:
 - an external package expects from system to support a certain
protocol, which can be used to access various system services
(in our case , this is a #globalMenuRegistry)
- an external package expects from menuRegistry to support a certain
protocol, which can be used to add menu entries and control other
various properties.

So, that's how we can at the same time keep system decoupled, and be
able to have a direct communications between service & consumer.
Just stop using globals and build the basic system infrastructure
based on message sends and protocols.

>> Cheers,
>>  - Andreas
> --
> Best regards,
> Igor Stasenko AKA sig.

Best regards,
Igor Stasenko AKA sig.

More information about the Squeak-dev mailing list