Self-interest August 2001

self-interest@lists.selflanguage.org

9 participants
8 discussions

Delegation and Self like things for Squeak
by Stephen Pair 31 Aug '01

31 Aug '01

The following is copied from the web page: http://spair.swiki.net/21 (which also contains screenshot). It thought it may be of interest to the people on this list. ------------- === Overview This change set adds delegation capabilities to the Squeak VM. It also extends some previous work on prototypes by Hans Martin Mosner to implement a Self-like (http://self.sunlabs.com) system within Squeak. Delegation is the act of forwarding a message to another object, but maintaining the original receiver such that sends to self in the new method context will be directed back to the delegating object. === Screenshot The following screenshot shows ProtoInspectors open on a family (literally) of objects. They are arranged according to their inheritance hierarchy. Slots with an asterisk denote parent slots (their behavior is inherited by the child). The image doesn't show it, but you may have any number of parent slots. <<see web page: http://spair.swiki.net/21>> === Implementation Details Two new bytecodes are added to the VM: singleExtendedDelegateBytecode doubleExtendedDelegateBytecode (but the compiler has not yet been modified to generate these bytecodes) Several new primtives are added to support delegation and reflection primitiveDelegate - added to Object as #delegate:, #delegate:with:, ...etc primitiveDelegateArgs - added to Object as #delegate:withArguments: The following primitives allow a Mirror to reflect on objects without needing to send messages to the reflectee (this allows mirror to manipulate objects that may have a very lightweight protocol): primitiveGetSlots primitiveSetSlots primitiveGetProtoBehavior primitiveSetProtoBehavior The message lookup algorithm is also modified to search the parent slots of objects whos class is an instance of ProtoBehavior. This allows for instance based, multiple inheritance. Bytecodes accessing the internal structure of an object (pushReceiverVariable and kin) are modified such that the look to the "receiverStorage" object in the active context. In normal messages receiverStorage is identical to receiver, but in delegated methods, they will be different. You may create object that inherit behavior from normal Smalltalk instances (direct instance variable manipulation will affect the parent object, not the child's slots). Hans Martin Mosner's HmmProtoObject class has been dropped in favor of the Mirror class and a reflection based approach to meta- programming in the spirit of Self. To add or remove slots or methods, you must use a mirror (unless you add methods to your instance). The ProtoInpector now uses a Mirror to manipulate an object. This allows objects to be inspected and manipulated even if they have no behavior. The VM has also been enhanced such that a recursive #doesNotUnderstand: will not crash the image, but lookup the #doesNotUnderstand: on Object (and you will get a #doesNotUnderstand: on a #doesNotUnderstand: message). This was done because the likelyhood of accidentally creating objects that don't understand #doesNotUnderstand: has increased dramatically with the introduction of ProtoBehavior. There should now be enough support in the VM to implement a pretty robust implementation of Self within Squeak. It would be really cool to see the Self tools for manipulating objects recreated in Squeak. === Issues The compiler has not been modified in any way, shape or form to implement anything like the Self syntax. This means that doing certain things can be awkward. Additionally, this means that you must use #delegate: or one of it's variants in order to accomplish what Self calls a "resend." Also, only a directed resend is possible. There is no way to store instance based source code, therefore, all methods appear in their de-compiled form. This is a pain. === Downloading There are three things that you can download: 1. A bundle that includes a demo image, changes file, and a Win32 VM 2. Just the change set (you will need to compile your own VM and follow the procedure below to get an existing image prepared to run on it) 3. Just the win32 VM (note, trying to run a base Squeak image on this VM won't get you very far very fast) If you are going to compile you own VM, you will need to load the change set, and then execute the following code in a workspace to prepare the existing method contexts in your image: MethodContext allInstances do: [ :ea | ea instVarNamed: #receiverMap put: ea receiver ]. Smalltalk snapshot: true andQuit: true. Then, you should have an image that will work on your new VM with support for delegation.

3 6

re: X-programming and Squeak
by John Hinsley 31 Aug '01

31 Aug '01

Albertina Lourenci <lourenci(a)lsi.usp.br> wrote: > (I work in pair or more always!!) I think that's by far the best way to work. Certainly all the projects I've done that were collaborative worked out the best. > I wonder whether you can imagine how extremely > grateful to you I am!!! I'm just glad to have been of help! As always, I'm bowled over by your energy and enthusiasm. If you've any to spare, do you think you could put it in a bottle and send it to me ;-) > Yes, I am surprised that I managed to read all code written in Smalltalk > and Squeak!!Is it Self's influence? > I'm not sure. But I think that the Squeak folk and the Self folk are on a very similar wavelength in wanting to create something which was both powerful and easy to use. Of course, the Morphic you see in Squeak is a port of Morphic in Self, and there may be more Self stuff coming over to Squeak. Happy Squeaking and may the Morph be with you! Cheers John -- Can't cope anymore? Desperate for help? Join the 12 step program for those who yearn to give up Microsoft: http://home.earthlink.net/~penguinrox/index.html

2 1

Model View Controller and the Observer pattern
by Albertina Lourenci 30 Aug '01

30 Aug '01

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

3 10

Re: Model View Controller and the Observer pattern
by John Hinsley 30 Aug '01

30 Aug '01

Albertina Lourenci <lourenci(a)lsi.usp.br> wrote: > And artists only feel attracted towards friendly things. Don't you find Squeak friendly and cute? > Could you please tell me where I can read more about this (MVC + Morphic)? Maybe a good place to start is John Maloney's paper http://coweb.cc.gatech.edu/squeakbook/35 (this is the chapter from Squeak: Open Personal Computing and Multimedia edited by Mark Guzdial and Kim Rose Prentice-Hall) On the Squeak list, John recently wrote: > Morphic is a graphical object system that's completely independent of > MVC; you can even remove MVC from a Morphic Squeak image entirely. > > The biggest difference is that Morphic has an incremental display update > system that allows many graphical objects to be animating or updating at > the same time, whereas in MVC only one window (controller) is active at > any given time. > > Morphic and MVC both have their strengths. MVC is better when memory > or processor cycles are in short supply. It is smaller, simpler, and more > efficient, but it doesn't do as many cool things. Morphic makes it easy to > have a lot of things happening at once, and it helps the programmer > create window contents that goes beyond text and list panes. Which is a pretty fair (albeit brief!) summary from the horse's mouth. Cheers John -- Can't cope anymore? Desperate for help? Join the 12 step program for those who yearn to give up Microsoft: http://home.earthlink.net/~penguinrox/index.html

2 2

Improvements to Self?
by Ian Woollard 24 Aug '01

24 Aug '01

Hi! Self interested people! I used to run Self 4.0 on a Sun system. It was kinda fun, but a bit limited in some ways- portability was quite poor; and some of the language concepts were a bit more irregular than I would have liked. Here are some of the ideas I have to improve it; I'd welcome some comments: a) 'references' Consider: a: b + 1 I think that a: should not be a slot. Instead 'a' should return a reference object; sending the message ':' to it would update the value. In the case of 'b' it should also return a slot object as well. Passing '+' to it would not be recognised, and would be overridden in the reference object to return the value b, which would then be passed the message. The idea is that the compiler/interpreter could optimise this away as the message would typically either match or not match for any given use. (There's a few wrinkles here I'm glossing over, but you should have the basic idea.) b) 'Allow optional parameters' For example, Self could have an object called 'Button' that might have optional parameters to set the font, size etc. This can reduce the size of APIs considerably. This allows Self to become a decent scripting language. c) No lexical scoping Methods instantiations should inherit off an assignable slot, that is set to point to self. Statements should inherit off method instantiations. This simplifies the language, and regularises it. (Again the compiler can optimise this away.) d) Privacy Some mechanism is needed for this. The minimal implementation is a slot that can only be accessed when called from a method found in a slot of self; but that's a bit cumbersome to code with. (If that sounds completely bizarre, don't worry, there are much better implementations.) Anyway. What do people think? Good/bad/implementation X does that already... -- - Ian Woollard (ian.woollard(a)tesco.net) "Is a planetary surface the right place for an expanding technological civilization?" - Gerard O'Neill

2 8

[Fwd:evolutive architecture
by Albertina Lourenci 15 Aug '01

15 Aug '01

Dear Selfers: Some time ago by January, I promised I would make available the outcome of my readings. Well the final Scientific Report for Foundation of Protection to Research of São Paulo State will be at my home pages by September. But right now I have a short position (4 pages) entitled An evolutive architecture reasons as a semiotic, hermeneutic and autopoietic entity. that I will present at the International Workshop on Principles of Software Evolution(IWPSE 2001) September 10-11, 2001, Vienna http://www.jaist.ac.jp/IWPSE2001/ in Vienna in September. I would like to receive your comments especially because I joined last ECOOP'01 in Budapest and talking to many language designers there I concluded that the lack of training of computer scientists in art makes it difficult for them to design or understand really interactive and expressive languages like Self. Many programmers there praised SElf/Us but do not know to do something similar or program in it. On the other hand, there is a growing consensus that OO paradigm is reaching stagnation. This is considered worse than a crisis. I look forward to your comments. Best wishes Albertina -- .----------------------------------------------------------. | Albertina Lourenci | | PhD in Architecture and Urbanism | | post-doctorate researcher | | Laboratory of Integrated Systems University of Sao Paulo | | Avenida Professor Luciano Gualberto, 158 Travessa 3 | | CEP: 05508-900 | | Sao Paulo Sao Paulo State Brazil | | Voice: +55 011 818 5254 | | Fax: +55 11 211 4574 | .----------------------------------------------------------.

2 6

Re: [self-interest] Class::Prototyped - Fast prototype-based programming in Perl
by Toby Everett 03 Aug '01

03 Aug '01

> Toby Everett and I have come up with a Perl module that gives Perl a > Self-like object model. If you're interested in using prototype-based > programming but can't get Self to work, you might consider this. Just to make a side note, one of the things we have demonstrated through this is that it is possible to add prototype-based semantics to class-based object-oriented languages that support run-time inspection and creation of classes. The metaphors of Self: prototype-based, mirrors and reflection, and slots, both data, method, and parent, all translated very well and proved very effective in what is still a very Perlish system. The end-result is that I can write Perl code using the approaches one uses in Self, and it is a very liberating and exciting feeling. One overloads the + operator by adding the method slot '+'. Classes and objects are both first-class citizens - they are virtually equivalent in the eyes of C::P (the only difference is that named classes persist even if there are no references to them, where as objects experience normal destructor behavior). Perl becomes a guise for Self:). I see no reason why this same thing couldn't be done in other dynamic class-based object-oriented languages. Basically, all one has to do is write a reflection system that uses the Self semantics and translates those into the native inspection system. --Toby Everett

4 3

Class::Prototyped - Fast prototype-based programming in Perl
by Ned Konz 02 Aug '01

02 Aug '01

Toby Everett and I have come up with a Perl module that gives Perl a Self-like object model. If you're interested in using prototype-based programming but can't get Self to work, you might consider this. One of the interesting things about this is that it uses Perl's built-in multiple inheritance and reflection support, and so allows mixing class-based and prototype-based idioms in a reasonably sensible (we think) manner. Tell us what you think. It's made Perl programming more interesting for us, at least! Currently, it's a bit of a memory hog (1.3K+ per object, ~3K for about 4 slots). It executes methods just as fast as native Perl method lookup, though. When we figure out a way to do it without sacrificing too much performance, we're going to come up with a version that uses less memory than this for clones (currently each Prototyped object has its own symbol table; we can share these for clones and do a copy-on-write as soon as we can come up with a way to handle data slots efficiently with this model). Here's a copy of the announcement I made to the comp.lang.perl.announce newsgroup: Class::Prototyped - Fast prototype-based OO programming in Perl Class::Prototyped version 0.11 has been released to CPAN. It is available from your local CPAN mirror as (for instance): http://www.cpan.org/modules/by-authors/id/N/NE/NEDKONZ/Class-Prototyped-0.1… or ftp://ftp.cpan.org/pub/CPAN/authors/id/N/NE/NEDKONZ/Class-Prototyped-0.11.t… This package provides for efficient and simple prototype-based programming in Perl. You can provide different subroutines for each object, and also have objects inherit their behavior and state from another object. Method invocation is as fast as in regular Perl. Data inheritance and accessors are provided using closures. It does not use AUTOLOAD. If you're familiar with the Self language, this will look quite familiar. If you find yourself using objects whose behavior is wholly or partially determined by closures or CODE references, you should consider trying this package. If you're modifying @ISA or symbol tables on the fly, you should consider using this package. If you're using Class::SelfMethods, Class::Classless, or Class::Object, you should _definitely_ consider using this package. Automatic delegation is also provided, as is a full reflection interface. You can do the following: * Make objects that live in their own classes * Inherit from objects _or_ classes * Add or remove methods from objects or classes dynamically * Modify inheritance dynamically * Automatically delegate specific methods to a particular object or class * Mix-in behavior simply from classes or objects * Examine the capabilities and inheritance of your objects and/or classes using a simple, consistent interface (no more inspecting @ISA or symbol tables) * Perl code in external files can be mixed in to the behavior of a class or object (like the way Ruby handles mixed-in modules). Class::Prototyped was written by Ned Konz and Toby Everett; we welcome feedback on its design and usage. Toby wrote Class::SelfMethods and is now using Class::Prototyped instead. -- Ned Konz currently: Stanwood, WA email: ned(a)bike-nomad.com homepage: http://bike-nomad.com

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

Self-interest August 2001