Self-interest April 1992

self-interest@lists.selflanguage.org

5 participants
6 discussions

Request for membership in Self mailing list
by tnt＠borland.com 28 Apr '92

28 Apr '92

Please add tnt(a)borland.com to the Self mailing list. Thanks in advance, Thomas Teng Language R&D Borland International

1 0

BOS1.2 release -- play it again, sam
by Sean.Levy＠cs.cmu.edu 23 Apr '92

23 Apr '92

[appologies to comp.lang.tcl readers for restating some things from my earilier post --S] Well, I screwed up and left out some files in my previous attempt at a release. I've added them, along with a very cursory but at least somewhat useful README at toplevel. You can pick it up and try it now, if you couldn't get anywhere with it before: anon ftp to monch.edrc.cmu.edu (128.2.214.44) user: anonymous password: your_user_id@your_host ftp> cd /usr0/snl/archive ftp> bin ftp> get bos-1.2.tar.Z N.B.:You have to cd to that and only that directory, due to CMUisms in ftpd. I should've also said, for the non-Tcl audience, that the BOS distribution I pointed y'all at is (a) not very pretty (some CVS crud directories left around, CMUisms in the makefiles), and (b) is ONLY BOS. BOS needs at least Tcl 6.2, and, if you want to play with GUI stuff, Tk 1.4. Both of these are available from hosts (hah) of anon FTP sites, all over the place. Also, some of the classes in base/ rely on Tk widgets that are not part of Tk, but rather are part of our own internal library of Tk widgets, which we have not had time to put into releaseable form yet (but Real Soon Now); this includes a bugfixed version of the Tk Text widget, several forms of DAG widgets (really nifty!), facilties for actually building widgets totally in Tcl (e.g. low-level X11 primitives that support messing with GCs, drawing text, lines, arcs, etc exported into Tcl), and several other nice widgets (a form widget, other stuff). Part of what I'm doing right now is BOSifying all of this... There is documentation under the libbos source directory, mainly programmer-level. There is also some documentation under the bosh directory. As a favor, I ask that anyone who gets this stuff to work on their local systems please send me email and tell me how hard (or easy) it was; I assume a certain level of hacker-ness, I know. If folks are having too many problems (and there are that many folks interested at all), I'll burn some time to make it easier (my priorities are necessarily fixed on other things at the moment, but since I have a machine at home (mixed blessing), I can take a few late nights to do cleanup work if it is worth it for enough people). Cheers, -- Sean -- Sean Levy <snl+(a)cmu.edu> `... from intuition we can pass to CMU Engineering Design Research Center analysis, but not from analysis to ndim Group intuition.' --Henri Bergson <-- Standard Disclaimers Apply -->

1 0

Re: BOS questions
by Sean.Levy＠cs.cmu.edu 23 Apr '92

23 Apr '92

[For readers of comp.object and self-interest, BOS is a prototype-based object system that I have, er, prototyped in Tcl. It is available via anon FTP to monch.edrc.cmu.edu under /usr0/snl/archive/bos-1.2.tar.Z (you have to cd to /usr0/snl/archive first and then get the file, due to CMU security hacks in ftpd). I thought that this would be of interest to comp.object and self-interest, so I'm cross-posting/mailing --S] Note: I play very fast and loose with the terminology of OOP to get my point across. I appoogize if I offend any sensibilities, and will clarify what I say if it is obfuscated by my use of terms. Excerpts from netnews.comp.lang.tcl: 23-Apr-92 BOS questions Tim Spurway(a)bcarh680.bnr (1601) > This posting is really directed at the designers of BOS, but I > thought that this dialouge would be of general interest, so I'm > putting it on the net instead of e-mail. > BOS is a prototype based object oriented system. This is different > from the traditional class based languages (like Smalltalk) in that > there is no distinction between an object (ie. an instance) and it's > class (ie. description of the object's behavior (type)). Everything's > an object. Now the questions ... > It seems that in BOS, everytime you create an object (by copying an > existing one), you have to give it a new name. Is this true? If so, > how is this name scoped (ie. is there only global objects?). Is there > a mechanism that allows for short-lived objects (ie. objects without > a name that are automatically cleaned up after use)? Can one simply > 'reference' an object without actually giving it a name? If not, why? The short answer is: no. The longer answer is that objects with local scope are targetted for the next version, and will go hand in hand with a mechanism for using objects as types, i.e. FooTraits defMethod something {Foo:anotherFoo} { Integer: i ... } The name i, which refers to an Integer object, and the Foo parameter anotherFoo are both local to the scope of the method something. I achieve this effect currently by doing things like: FooTraits defMethod something {anotherFoo} { set i [System gensym] Integer copy $i ... $i die } The object $i is "global" in the sense that it is accessible outside of the scope of something, but the actual name held by $i is really only known to something (pragmatic local scope :-). Also, anotherFoo could be any kind of object, although something assumes (presumably) that it is another Foo object. I view the lack of a type system in BOS as being the root of both problems, and will address them together. Note that I am extending the syntax of BOS with my "Integer: i" construct; to really do a type system in BOS, I am going to have to stop using Tcl_Eval as my interpreter for methods and write my own parser that "wraps" Tcl_Eval (maybe: actually, I am not sure if I want to even allow arbitrary Tcl code in methods in the next release, since this comlicates things somewhat -- some input on this from folks would be nice). Note that I don't WANT to impose a type system on Tcl itself -- I think Tcl is perfectly fine as it is in this respect. The relationship between BOS and Tcl is somewhat symbiotic, conceptually -- the fact that the relationship of this implementation of BOS is more than symbiotic (it is a downright dependency!) is due to the fact that I wanted to start working with a prototype-based object system quickly. > What about garbage collection? Does it make sense to garbage collect > in a system like BOS? Yes, it does. Yes, it is coming. I think I may be taking a slightly different approach than what has been done in other systems, but until it is finished and the details worked out, I can't say for sure. More later. > In BOS, the 'inheritence' mechanism is very general. Single and multiple > inheritence is very easy to achieve using priorities on the objects you > want to have searched for a given method. As a matter of fact, dynamic > inheritence is a very feasable possibility in this system (neat!). What > is a good example of how dynamic inheritence can be used? What kinds of > problems is it appropriate for? How does the message lookup mechanism > deal with objects that have the same priority? The point in dynamic inheritance could be responded to with a whole article. I will try to write down some things on this vis a vis my application of BOS and post later. The message lookup mechanism deals with objects that have the same priority by, effectively, tossing a coin. In this respect I have not taken advantage of the work done by the SELF people, since experimenting with various sorts of inheritance was not my primary concern (it is one of theirs). In fact, my use of the system has been strictly in a single-inheritance style! > What's a good book on prototype based systems? You should get The SELF Papers, by the SELF group (formerly at stanford, now at Sun, I believe). It used to be available by anon FTP to self.stanford.edu, I think, but I'm not sure anymore. I have them, but am not sure if I am allowed to make them available if they are not from some other source (legalities and such...). There is a SELF mailing group: self-interest(a)self.stanford.edu. You can get on it by emailing self-interest-request(a)self.stanford.edu. If SELF had been available in source form and had been more portable a year ago, I might never had bothered to write BOS. As it is, I'm so deeply into it, that I'm beginning to see why maybe I want BOS and not SELF, but I'm really not sure about that. I'm not sure where else in the OOP literature there is information on prototype-based systems, but in my area (Engineering Design) there are some papers on the suitability of prototype-based systems for work in design, vs. class-based systems. I can look up the references and email and/or post them if you like. > Thanks in advance. > Bell Northern Research > tims(a)bnr.ca > == Cheers, -- Sean -- Sean Levy <snl+(a)cmu.edu> `... from intuition we can pass to CMU Engineering Design Research Center analysis, but not from analysis to ndim Group intuition.' --Henri Bergson <-- Standard Disclaimers Apply -->

1 0

Re: Self question
by Bay.Chang＠Eng.Sun.COM 03 Apr '92

03 Apr '92

> Can someone tell me why this works: > >_AddSlots: (| str = ('This is a string.') |) > >str do: [ | :i | i print ] > > for printing a string but this: > > >str reverseDo: [ | :i | i print ] > > doesn't, for printing a string in reverse order? reverseDo: isn't defined for strings in the current release--it's only defined for lists. The error you are getting is "message not understood." (In the upcoming release your example would work, because reverseDo: is defined for more collections, including indexable objects [like strings].) Feel free to send further questions directly to me, unless you think they might be of interest to others on the self-interest list. Bay

1 0

Self question
by danny＠cs.ttu.edu 03 Apr '92

03 Apr '92

1 0

Sample program
by danny＠cs.ttu.edu 02 Apr '92

02 Apr '92

Bay sent me the following program to reverse a string of characters: _AddSlotsIfAbsent: ( | danny = () | ) danny _Define: ( | parent* = traits oddball. reverse: str = ( | rev <- '' | str do: [ | :c | rev: c, rev ]. rev ). | ) I did the _RunScript on this file and it went fine. However, when I type in " reverse: 'backwards' " I received this message not understood error: Message not understood Message type: ImplicitSelf Receiver: <4>: lobby Selector: reverse: Arguments: vector{'backwards'} MethodHolder: <4>: lobby Can you tell what I am doing wrong? Also, I am having trouble using the list-specific selectors for collections. Do I need to define the objects in a special way for these selectors? I do not seem to be having any trouble with the other selectors. Thanks, Danny Travis danny(a)cs4sun.cs.ttu.edu

2 1

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 April 1992