the ability to act as components and/or containers

But this deserves more attention as the Composite pattern it represents is one of the most important and pervasive patterns in practice because things in the “real” world are always contained and often contain other things. Back in the mid-1980’s the integrated software environment, Framework, written by Xerox PARC alum Robert Carr demonstrated to me that there were significant benefits to orgainizing everything into a hierarchy of objects. Carr won a Profile In Technical Excellence award in 1985 for Framework. One of the benefits of the Framework approach was that there was no notion of “applications” and the degree of interoperability was astounding and still some 20 years later unsurpassed in a number of respects. MC2 brings back the kind of easy interoperability seen in Framework but missing in Smalltalk. Sure if you are a knowledgeable Smalltalker, you can integrate any two solutions but each one tends to be a special case. Often you end up having to gain a deep understanding of an object just to do something relatively simple with it. In some cases you end up having to analyze whether to refactor the class or create a subclass. With Morphtron you can take existing objects and use them together quickly and easily. As a simple example take two tools that come with Squeak the MPEG movie player and Sound Recorder. Suppose you want objects that have movie players which have their own sound recorders:

myMediaRoom:=Object newNamed: ‘myMediaRoom’.
m_(MPEGMoviePlayerMorph newNamed: ‘Movie Player’) openInWorld.
myMediaRoom addComponent: m.
s:=( RecordingControlsMorph newNamed: ‘Sound Recorder’) openInWorld
m addComponent: s.

m fullName ‘/myMediaRoom/Movie Player’
s fullName ‘/myMediaRoom/Movie Player/Sound Recorder’

No refactoring, no new subclasses, just the capabilities you wanted to create from two classes you didn’t author.

o_Object new.
o getComponents an OrderedCollection()
o getComponentsNamed: ‘boo’ an OrderedCollection()

o componentName ‘an Object’
o componentName: ‘hello’
o componentName ‘hello’

oc_Object newNamed: ‘world’.
o addComponent: oc.
o getComponents an OrderedCollection(an Object)
oc container componentName ‘hello’
oc fullName ‘/hello/world’

props_Dictionary new.
props at: #mySpecialTrait put: ‘is flexibility - hooray Morphtrons!’
op_Object newNamed: ‘h2′ withProperties: props.
op fetchProperty: #mySpecialTrait ‘is flexibility - hooray Morphtrons!’

op_Object newNamed: ‘h2′ withProperties: {#mySpecialTrait. ‘is flexibility - hooray Morphtrons!’}
op fetchProperty: #mySpecialTrait

• the ability to act as components and/or containers
• the ability to be referred to by name(both short and full path)
• a consistent, robust creation and initialization protocol

• Browser based
• Yahoo Widget Engine(put the MOPA.js file from above into the .kon file)

so the only differences in them have to do with output. I know that earlier versions of Morphtron ran in Javascript OSA and Web Crossing but I haven’t tested this particular file with them - so many platforms, so little time.

The thought is that the web will become a distributed object oriented space. Then the question is how to interact with it, and how to navigate and how it’s displayed. Squeak gives wonderful control over that, we must exploit that.
Squeakend 2000

At that time the outliner was often in the spotlight and the code base was not as flexible or modular as it is today. Here’s a screenshot from that era:

There’s been a lot of evolution since then - the outliner has taken its place in a larger 3D world but the core concepts have remained the same.

create a new object
o_Object new. an Object

see if it has a ‘hello world’ property
o fetchProperty: ‘hello world’. nil
put something into the hello world property
o putIntoProperty: {’hello world’. ‘first program’}

fetch the new property
o fetchProperty: ‘hello world’. ‘first program’

when you fetch all of an object’s properties, you get all the methods and instance variables along with the accessories
o fetchProperties a Dictionary(size 453)