Dear Selfers:
Something really honourable is the way the GOF strives to make things as clear and neat as possible: to really want to convey experience! Since Frank Buschman believes I can implement the design patterns in Self and since I do not see any better language to achieve my goals I would like you to help me. By the end of the last millennium Jecel talked generically about the relationships of design patterns with Self. Now I have a very specific question and for me it is very important it is answered in a scientifc way!!!In the excellent book written by Alpert, Brown and Woolf entitled The Design Patterns Smalltalk Companion 1997 to work as a complementary book to the Design Patterns from the GOF dealing only with their implementation in Smalltalk and related applications, they write: A third kind of relationships between objects in Smalltalk-80 is the ability of an object to register itself as a dependent of another
object. This third type, the dependency relationship used to "coordinate activities between different objects" is the Observer pattern. It is used to communicate between layers in an architecture. Its best known use is in the Model-View-Controller (MVC) framework for implementing the user interface. As fundamental as the Observer appears to be in Smalltalk it is not a language feature (language feature and construct is the same thing?); it is a feature of most Smalltalk libraries. Every dialect implements it differently. The proposed ANSI Smalltalk standard doesn't include Observer at all. Furthermore, window painters and other visual programming tools automate the use of Observer so that programmers often don't use it directly anymore. Nevertheless Observer is a significant feature in Smalltalk that Smalltalk programmers should understand. The Observer pattern is implemented by the change/update protocol, introduced in Smalltalk-80 and still used in VisualWorks today. It is implemented in object as a combination of the subject and observer classes. This enables any object to a subject, an observer or both.
With change/update the dependency relationships between objects are difficult to follow. Then one can follow the variants and adaptations made to the change/update protocol along the dialects of Smalltalk to make it palatable!!! Although the GOF inspired on the architect Alexander, indeed Alexander is not a typical architect. I mean one that reasons economically and with images!!! They say they transmit experience. To be able to reach the point of knowledge I have today it took me a year to search for and have in my hands all the books that allow me to have a clear idea of at least one pattern (A system of patterns, pattern-oriented software aarchitecture Frank Buschman et al) and of course plus a thousand of papers about the GOf, plus tutorials and so on!!!! To start concluding something about how intelligible and acceptable this experience is, I need to know how the Self dialect deals with the same issue!!! Of course the plenty of details is welcome if it favours understanding! Have a fun-filled creative peaceful weekend, Albertina
Albertina,
Now I have a very specific question and for me it is very important it is answered in a scientifc way!!!
I think you ended up forgetting your question, for I didn't find it in the rest of the text. So I will suppose that you are interested in known if Self has an implementation of the Observer Pattern similar to Smalltalk-80.
The answer is: no. Morphic handles this in a less flexible way than MVC. Each object sends "changed" to itself whenever its internal state is changed and the same object should do something about it. The idea in Morphic is that each object should appear only once on the screen and so we don't need multiple viewers.
An exception to this is outliners, which when representing a morph can be on the screen at the same time as the morph itself. The morph "view" is updated by the "changed" code, but the outliner isn't. Instead, the outliner uses the periodic "step" method to poll the object and see if anything has changed. This is not efficient, but gets the job done. This is why an outliner sometimes takes several seconds to reflect changes to an object you have sent a message to.
Please note that the original creators of MVC are now using Morphic exclusively.
As fundamental as the Observer appears to be in Smalltalk it is not a language feature (language feature and construct is the same thing?); it is a feature of most Smalltalk libraries.
Yes: language feature and language construct is the same thing. No: Observer is not a fundamental Smalltalk pattern. It is key to MVC, but you can have Smalltalks with other graphical systems and not need it at all. So it is a good thing that the ANSI standard ignores it.
-- Jecel
Jecel,
I think very highly of all of your postings but this time I have to disagree.
Please note that the original creators of MVC are now using Morphic exclusively.
AFAIK, the original creator of MVC was Trygve Reenskaug and not the group involving Dan Ingalls and Alan Kay you are referring to.
Also, said Squeak group still maintains both MVC and Morphic. Moreover, even if they exclusively went the Morphic direction that would just tells you that for their particular purposes the direct manipulation and stepping paradigm does the job. It does not, however, imply that Morphic is the better choice in all circumstances. In fact, the current Squeak way of supporting Morphic is badly in need of a polish, AFAIC. It is way to slow for anything but the most minute toy examples.
Peace and Luck,
Thomas
-- Dr. Thomas Kuehne +49 178 4314387, http://www-agce.informatik.uni-kl.de/~kuehne Experts are people who successfully calibrated their intuition. -- TK
Thomas Kuehne wrote: Dear Thomas:
Please note that the original creators of MVC are now using Morphic
exclusively.
AFAIK, the original creator of MVC was Trygve Reenskaug and not the group involving Dan Ingalls and Alan Kay you are referring to.
Also, said Squeak group still maintains both MVC and Morphic.
This sounds intriguing. Is Squeak a dialect from Smalltalk? They offered a tutorial about Squeak in the last ECOOP'01. I was busy with the Workshop on OOAE and their tutorial was not at all intelligible. It looks like the Self manual where no explanation about collections was given. I had to figure out by myself that all the methods there were similar to those from Smalltalk .Then I picked up the Smalltalk books and studied. You may agree this is at least not friendly. And artists only feel attracted towards friendly things. Could you please tell me where I can read more about this (MVC + Morphic)?
Moreover, even if they exclusively went the Morphic direction that would just tells you that for their particular purposes the direct manipulation and stepping paradigm does the job. It does not, however, imply that Morphic is the better choice in all circumstances.
Indeed the Morphic arrangement based on rowMorphs and columnMorphs is very rigid! However the underlying philosophy is nice!
In fact, the current Squeak way of supporting Morphic is badly in need of a polish, AFAIC(What's this?) It is way to slow for anything but the most minute toy examples.
Peace and Luck, This is all I need to be creative!
The same for you, too! Albertina
Thomas-- Dr. Thomas Kuehne +49 178 4314387, http://www-agce.informatik.uni-kl.de/~kuehne Experts are people who successfully calibrated their intuition. -- TK
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Albertina Lourenci wrote:
This sounds intriguing. Is Squeak a dialect from Smalltalk?
Yes, it is a derivate from Smalltalk-80 which offers many multimedia features, such as, 3D graphics, sound, internet awareness, speech creation, frequency analysis, etc.
Then I picked up the Smalltalk books and studied. You may agree this is at least not friendly. And artists only feel attracted towards friendly things.
I understand. I guess Squeak presupposes a familiarity with Smalltalk. It is not a product but an open source effort (akin to Linux). Starting from www.squeak.org (on to the swiki) you should find many tutorials though.
Perhaps you'll find the educational material (developed with Squeak) at www.squeakland.org interesting. To view it you'll need to install a Sqeak plugin but this is a very painless process and certainly worth your while.
Indeed the Morphic arrangement based on rowMorphs and columnMorphs is very rigid!
Note that this is nothing inherent to the Morphic approach. It is just a particular use of morphs.
Regards,
Thomas
-- Dr. Thomas Kuehne +49 178 4314387, http://www-agce.informatik.uni-kl.de/~kuehne Experts are people who successfully calibrated their intuition. -- TK
Thomas Kuehne wrote:
Dear Thomas:
This sounds intriguing. Is Squeak a dialect from Smalltalk?
Yes, it is a derivate from Smalltalk-80 which offers many multimedia features, such as, 3D graphics, sound, internet awareness, speech creation, frequency analysis, etc.
This sounds great! Java has sort of these facilities. But to program in Java is rather nasty! I do not think I am being biased because I do need to program with the prototypes!!! I have been reading interesting work and of course they all program in class-based language such as design patterns implemented in C++ (simply a nightmare to understand!), then reuse contracts by Patrick Steyaert and so on!!I love Patrick's open computation systems!! But this stuff with reuse contracts programmed in class based languages is simply an endless swirl of trying to follow a class hierarchy that only exists in Patrick's mind!!! I mean they do not want to accept the arbitrary nature of the real world and try to curb it to class hierarchy. The outcome is obviously nasty!!! Autopoietic (or recursive) reasoning is much more complex and thrive on a simple and the same construct that you combine and repeat over and over again. Yet the outcome is always unexpected and perfectly ordered!!! Indeed I have a bad memory. I can only remember structured things. And the current stage of programming is based on components or things that interact with each other. There is no structuring!!I will talk about this in my Scientific Report.
Then I picked up the Smalltalk books and studied. You may agree this is at least not friendly. And artists only feel attracted towards friendly things.
Honestly I could read Eiffel, Sather, CLOS but not Smalltalk. Then I agree with Randy and Dave when they simplified SMalltalk and made Self! Yet I am not happy with what I read about Self. Having read Beta and the Mjoelner Beta system books I could understand how the programming environment works. It is nice!! And yet they only display a collection of papers. In Self I have no idea how to deal with the debugger for example!!So one cannot program anything if one does not know how to deal with the debugger!! Moreover, I think Self is like biochemistry. You have to know all the specific enzymes to understand about protein digestion or carbohydrate digestion and so on.This requires memory again and I almost gave up scientific high school studies due to zoology, biochemistry and organical chemistry!! I realize today reductionism may also lead to global reasoning but it is not my mind architecture!!
I understand. I guess Squeak presupposes a familiarity with Smalltalk. It is not a product but an open source effort (akin to Linux). Starting from www.squeak.org (on to the swiki) you should find many tutorials though.
Perhaps you'll find the educational material (developed with Squeak) at www.squeakland.org interesting. To view it you'll need to install a Sqeak plugin but this is a very painless process and certainly worth your while.
I thank you for the references because I noticed that although it sounds like biochemistry it has some structuring and it is relatively easy for me to follow code implementation in Smalltalk and Squeak better than C++. Now the attempts of integrating delegation into class-based language I feel as really unnecessary complicated!! Jan Bosch tries to structure design, he has great insights but yet his introduction of layers and implementation in C++ sounds rather worksome!!
Indeed the Morphic arrangement based on rowMorphs and columnMorphs is very rigid!
Note that this is nothing inherent to the Morphic approach. It is just a particular use of morphs.
This sounds great! I think if Randy and Dave tried to be more didactic and explained the underpinnings of exploratory programming rather than rely on previous knowledge about Smalltalk would help a great deal. I do not understand until today how Smalltalk is based on objects and then the user has to program in class!!!For me this is a nightmare!!!As far I have been reading hardly ever this class category really fit anything like hand and glove in the real world!
I express my thanks deeply for your concerns towards my needs.
Have a fun-filled creative weekend, Albertina
Regards,
Thomas-- Dr. Thomas Kuehne +49 178 4314387, http://www-agce.informatik.uni-kl.de/~kuehne Experts are people who successfully calibrated their intuition. -- TK
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
On Monday 27 August 2001 03:13, Thomas Kuehne wrote:
AFAIK, the original creator of MVC was Trygve Reenskaug and not the group involving Dan Ingalls and Alan Kay you are referring to.
Thanks for the correction.
http://www.martinfowler.com/isa/mvc.html
Having only seen pictures of Smalltalks before -80, I wasn't aware that their user interfaces were not MVC based (since they look so similar).
Also, said Squeak group still maintains both MVC and Morphic.
True, in a sense. And they have promised to continue having support for MVC applications in the future. I was just mentioning that more and more Squeak applications break if you try to run them under MVC. All new code at "Squeak Central" is Morphic.
Moreover, even if they exclusively went the Morphic direction that would just tells you that for their particular purposes the direct manipulation and stepping paradigm does the job.
Exactly.
It does not, however, imply that Morphic is the better choice in all circumstances. In fact, the current Squeak way of supporting Morphic is badly in need of a polish, AFAIC. It is way to slow for anything but the most minute toy examples.
Morphic is much less efficient than MVC and isn't practical except on the most modern computers. It certainly wouldn't have been reasonable on the type of machines Smalltalk ran on for the first 25 years. People are not finding it very usable on current PDA devices.
Morphic is based on the "one object, one view" philosophy. If you want multiple views (a chart and a spreadsheet on the same set of numbers) then it won't work for you. That is not true of Morphic in a subjective language like Us, however.
Morphic isn't a good match for a single inheritance class based language like Squeak Smalltalk. A PieChartMorph will extend an object like FancyDictionary (by having one at its parent) to have a graphical representation. In a class based language, having an instance of PieChartView delegate to an instance of FancyDictionary wouldn't work too well (we want data to flow *from* aFancyDictionary *to* aPieChartView and the Observer Pattern does that). In other words, in Morphic a View *is* a Model. The only way to have that in Squeak is to merge both classes into one. In order for that not to be come too nasty they use a dictionary to allow per instance "slots".
Different tools for different jobs is what I always say. And no tool is ever better than another in an absolute sense. So I don't think we disagree at all except, perhaps, for my point that it is not unreasonable to have a Smalltalk without the Observer Pattern.
-- Jecel
Jecel Assumpcao Jr wrote:
Morphic is based on the "one object, one view" philosophy. If you want multiple views (a chart and a spreadsheet on the same set of numbers) then it won't work for you. That is not true of Morphic in a subjective language like Us, however.
OK!But you told me that nobody knows how to implement layers and views in an efficient way. The way these are implemented in Sina (from the Mehmet Aksit group) through composition filters and in C++ , views and layers cannot be expressed explicitly in the object model but are implemented as pieces of method code and messages between objects. It is difficult to follow the traceability of the implementation model with respect to the design model. A unit in the design model does not have a corresponding unit in the implementation model.The implementation models the real world problem less exact than possible. Then those that want to build software systems whose levels exhibit isomorphic behaviour are rather interested in developing architectures that are faithful to the domain model. And of course design pattern oriented architectures fulfill the promise for more expressiveness. Especially because a designer can invent as many patterns as he/she wishes to reflect his/her intentions.
Even if there were a successful implementation of Us, one cannot forget about the architectural level. The trend of treating relations as components or first-order entities seems well expressed in the agent based approach. However I do not know in which language they are implementing these ideas.
Best wishes Albertina
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Albertina,
Jecel Assumpcao Jr wrote: Morphic is based on the "one object, one view" philosophy. If you want multiple views (a chart and a spreadsheet on the same set of numbers) then it won't work for you. That is not true of Morphic in a subjective language like Us, however.
OK!But you told me that nobody knows how to implement layers and views in an efficient way.
I am working on this. There are still some issues remaining to be solved, but it is likely that this feature will be available in Self/R. Comments welcome at http://www.merlintec.com:8080/software/8
Sorry that I won't be able to answer your many questions this week, but I will be away on a trip (Comdex Brazil). -- Jecel
Dear Selfers:
I am going to try to show you why I am not able to program in Self alone without help of an experienced programmer. For example: I am going to show you that this is even language-independent because I do not understand it in the Presentation Abstraction Control architectural pattern from Buschman. This pattern has similar functionality to MVC. Here each agent has a presentation, an abstraction and a control component! Of course instead of understanding its real nature, this pattern is curbed to follow a tree-like hierarchy of PAC agents. The main responsibility of the top-level PAC agent is to provide the global data model of the software. This is maintained in the abstraction component of the top-level agent.
The interface of the abstarction component offers functions to manipulate the data model and to retrieve information about it.
Now the representation of data within the abstraction component is media- independent. For example, in a CAD system for architecture, walls doors and windows are represented in cm or inches that refelct their real size, not in pixels for display purposes.This media-independency supports adaptation of the PAC agent to different environments without major changes in its abstraction component. page 148 in A system of Patterns Buschmann et al, John Wiley 1999
Now I am going to reproduce a similar problem in the Morphic System. Jecel wrote this for me and I put it into my last Scientific Report:
The main aim of this application is the screen. Based on the experience of DraftScreen, that was derived from Morph pattern Self 4.0 obviously it was born already with some functionality: its colour and size can be altered by blue menu, it can be dragged to another place with the mouse and other morphs can be embedded into it. The most important change to a simple Morph was the inclusion of the notion of scale. All SElf 4.0 graphical interface was developed around entities that are measured in pixels (points in the screen), but the architect needs to think in terms of entities measured in meters and that can be represented on the screen by difrerent scales (depending on the interest in the moment). Hence each screen has a value 'rawScale'that multiplied by a measure in meters gives as outcome a measure in pixels fit to use by the graphical interface.
Of course all this sounds like Greek to me!!!!
The architect can specify the scale as a relation of measures (75:1; 25:1; 1000:1 and so on) Then he calculated a conversion factor (çonvFactor - 2834.6) that works for 17 inches-screens as a typical resolution for Sun Stations. For another kind of screen or impression in paper, another more sophisticated conversion system should have to be developed.
Another cosmetic screen feature is its basic drawing method ('baseDrawOn: ') It was altered to indicate small black points regularly spaced to ease the lay out of elements of the drawing. The number 'rawGRid' means the distance in meters between these two points. When the scale is taken into account, the small points of the grid are less than 10 pixels from each other, a value 10 times bigger is used to ease manipulation of the drawing.
Well other graphical languages used in this laboratory are manipulated by undergraduate architectural students with relative ease!!!!For example a professor here deals with graphical languages programmed in C to build virtual reality scenery of anything, architecture, surgical operations and so on. Of course each poor architectural student has to develop just one single building and adapt the methodology to deal with just one single building...It takes them a year to do so!!!!!This is for Euclidean Geometry. I wonder how complex it would become to represent free shapes with symmetry groups of the plane involved and so on. But the important point here is that they build artifacts and program. And they do not know anything about programming languages. I think this is amazing. Why Self should not be that simple? Why are the operations above like magic to me?
Best wishes Albertina
Jecel Assumpcao Jr wrote:
Dear Jecel: Thanks for your prompt reply.My question would be obviously how to reflect isomorphically the highly interactive nature of the domain model (ecodesign model + geometric modeling) of my knowledge system into the "software architectural level" (evidently of a hybrid nature = domain architecture + software architecture). So the architecture level like a Janus face looks back into the domain model and forward to the implementation level. The word constraint in architecture is not good because the language of architecture has the nature of the Chinese language. In Chinese any word can behave as a verb, as a noun, as an adjective, as an adverb. It depends on the context. So is architecture.If an architectonic element is chosen as a verb (see the attachments mopst and mpstw) this gives rise to the architectonic party. So if you stress the thermal comfort you have solar houses!!!!If you stress acoustics you have Sydney Opera House, if you stress structure you have the architecture of Luigi Pier Nervi!!!! Well a sustainable architecture in a highly sustainable region would dovetail harmoniously all the architectonic elements. So the core data would consist of all the requirements of the architectonic elements (better stored in a database due to complexity). Then we would call from the database the data about the climate of the city, the geoengineering data of the bioregion and so on. In the application model, the designer has to input data specific for designing one ecobuilding in a specific site.
The model in the attachment has to add the electrical systems for sensors, actuators to control the internal temperature of the building.
It is there independent of the use by clients and designers. It is naturally decoupled from the "user interface". One is going to choose them dependent on the budget and the resources available.
Moreover most of the time this data is also represented graphically (see the attachment (substanceofthe function = substancia da função - beautifully implemented in Self by Jecel!Heartfelt thanks!).The designer varies the input according to the ecology of the behaviour of the human being along its life cycle - baby ...until old age). In reality there would be a team of designers responsible for each architectonic element presenting in the view model their specific solution in a first step. So it would be interesting to present it as in the MVC where the core data of an election (votes+ parties) may be exhibited in the the view component as pie chart, bar chart parliament, spreadsheet and so on. Differently from the election case, of course each designer would choose different data adapted to the ecobuilding. In the view component there should be "a morph like the screenmorph we created to simulate sketching at free hand". Then a tilingMorph to apply crystallographic groups. At the next step each designer should be seeing all the solutions of the other designers and then start interaction to compose a single solution for the free plan of the floor of the ecobuilding. This step one uses the subgroup relationships of the crystrallographic groups that smoothly transforms or adapts one form into the other. Before reading about MVC I thought this could be made nicely through the programmable multiuser virtual reality Kansas. But this can also be reproduced by the main architectural designer for simple cases (indeed the need for at least the structural engineer is always a must). So my idea is to apply my semiotic knowledge and redesign an Observer pattern elegantly adapted to fit the case above. So when the thermal comfort expert changes the free plan, the architect must be aware of the change and reflect them back into the free plan concerned with the ecology of the human being when he lays out the furniture. The philosophy of programming of the Self language totally based on creation of analogies plus the unifying paradigm of human-machine interaction is fundamental for the architectural design. This interaction is also characterized as hermeneutic or the way art is. I also have to be concerned with the autopoietic aspect of my ecodesign model essentially based on recursive and reflective abilities enhancing evolvability from the microworld to the macro world. Hope I have conveyed my ideas neatly.Obviously I am not at all interested in programming in class-based languages.Simply because the objects in architecture have an arbitrary, individualistic nature. However they can grow from each other based on analogies. Like the morphic nature.
Any suggestion from the Selfers is welcome.
Best wishes Albertina
Albertina,
Now I have a very specific question and for me it is very important it is answered in a scientifc way!!!
I think you ended up forgetting your question, for I didn't find it in the rest of the text. So I will suppose that you are interested in known if Self has an implementation of the Observer Pattern similar to Smalltalk-80.
The answer is: no. Morphic handles this in a less flexible way than MVC. Each object sends "changed" to itself whenever its internal state is changed and the same object should do something about it. The idea in Morphic is that each object should appear only once on the screen and so we don't need multiple viewers.
An exception to this is outliners, which when representing a morph can be on the screen at the same time as the morph itself. The morph "view" is updated by the "changed" code, but the outliner isn't. Instead, the outliner uses the periodic "step" method to poll the object and see if anything has changed. This is not efficient, but gets the job done. This is why an outliner sometimes takes several seconds to reflect changes to an object you have sent a message to.
Please note that the original creators of MVC are now using Morphic exclusively.
As fundamental as the Observer appears to be in Smalltalk it is not a language feature (language feature and construct is the same thing?); it is a feature of most Smalltalk libraries.
Yes: language feature and language construct is the same thing. No: Observer is not a fundamental Smalltalk pattern. It is key to MVC, but you can have Smalltalks with other graphical systems and not need it at all. So it is a good thing that the ANSI standard ignores it.
-- Jecel
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
self-interest@lists.selflanguage.org
-
Albertina Lourenci -
Jecel Assumpcao Jr -
Thomas Kuehne