Self-interest March 1996

self-interest@lists.selflanguage.org

6 participants
6 discussions

Re: Add to list
by dentoy＠usit.net 26 Mar '96

26 Mar '96

Hi, Somehow this got to my machine, maybe I was sent a carbon copy? ... but I don't see it in the header shown below, so I believe it must be an error of some sort, maybe the em address. I'll send copy of this also as it appears to be originally addressed. Dennis //---quoted------------------------------------------------------- > X-Mailer: Windows Eudora Version 1.4.4 > MIME-Version: 1.0 > Date: Thu, 21 Mar 96 15:13:10 +0000 > From: nmyatt(a)vmark.co.uk > To: self-interest(a)self.smli.com > Subject: Add to list > > Please add my name to your list. > > Neville Myatt > > > Dennis dentoy(a)usit.net

1 0

Add to list
by nmyatt＠vmark.co.uk 21 Mar '96

21 Mar '96

Please add my name to your list. Neville Myatt

1 0

unsubscribe
by laurence hewes 15 Mar '96

15 Mar '96

unsubscribe self-interest

1 0

subscribe self-interest
by Stefan Derdak 15 Mar '96

15 Mar '96

subscribe self-interest

1 0

Subject: ECOOP'96 Workshop on Prototype Based OOP - 9 July 1996
by James Noble 12 Mar '96

12 Mar '96

Call For Participation ECOOP' 96 Workshop WS14 Prototype Based Object Oriented Programming Tuesday, 9 July 1996 Linz, Austria In the recent years an alternative to the traditional class-based object-oriented language model has emerged. In this prototype-based paradigm there are no classes. Rather, new kinds of objects are formed more directly by composing concrete, full-fledged objects, which are often referred to as prototypes. When compared to class-based languages, prototype-based languages are conceptually simpler, and have many other characteristics that make them appealing especially for the development of evolving, exploratory and/or distributed software systems. The distinction between class-based and prototype-based systems reflects a long-lasting philosophical dispute concerning the representation of abstractions. Plato viewed forms -- stable, abstract, "ideal" descriptions of things -- as having an existence more real than instances of those things in the real world. Class-based languages such as Smalltalk, C++ or Simula are Platonic in their explicit use of classes to represent similarity among collections of objects. Prototype-based systems such as Self, NewtonScript, GlyphicScript or Omega represent another view of the world, in which one does not rely so much on advance categorization and classification, but rather tries to make the concepts in the problem domain as tangible and intuitive as possible. A typical argument in favor of prototypes is that people seem to be a lot better at dealing with specific examples first, then generalizing from them, than they are at absorbing general abstract principles first and later applying them in particular cases. Prototypes give rise to a broad spectrum of interesting technical, conceptual and philosophical issues. Different variations of prototype-based object-oriented programming exist, and the terminology in the field is still somewhat diverse. The best known prototype-based programming language is Self, but there are many other interesting languages, as discussed in recent conference papers and panel discussions. In this workshop we examine the state-of-the-art in prototype-based object-oriented programming, focusing especially on the following question: how to make the prototype-based paradigm ready for the prime-time, i.e., to match/exceed the requirements and expectations of larger-scale, industrial software developers. Topics to be potentially discussed in the workshop include, but are not limited to: * different models of prototype-based programming, * experiences in implementing prototype-based systems, * experiences in using prototype-based systems, * guidelines, idioms and patterns for programming with prototypes, * analysis and design techniques for the development of prototype-based systems, * research directions for prototype-based programming. Potential workshop participants are requested to submit a short paper (2-5 pages) by April 29 to the address below (e-mail in PostScript or ASCII format is preferred): Antero Taivalsaari Nokia Research Center Software Technology Laboratory P.O. Box 45 00211 Helsinki, FINLAND taivalsa(a)research.nokia.com Participants reporting on experience are invited to indicate if they want to provide a short (less than 15 min) demonstration or videotape to illustrate their report in the workshop. Attendance to the workshop will be limited to approximately 20 participants to enable fruitful discussion. Organizers: Antero Taivalsaari Nokia Research Center Software Technology Laboratory P.O. Box 45 00211 Helsinki, FINLAND taivalsa(a)research.nokia.com James Noble School of Computing Sciences University of Technology, Sydney Box 123 Broadway, NSW 2007 Australia kjx(a)socs.uts.edu.au

1 0

method objects
by Jecel Assumpcao Jr 07 Mar '96

07 Mar '96

Self method objects have slots corresponding to the arguments and "local variables" and a pseudo slot called <code>. The code object has slots named source, fileName, lineNum, literals and codes. Is this still true for Self 4.0? I was wondering if it wouldn't be better to include all these slots as pseudo slots in the method object itself in order to get rid of the <code> object. It seems to me that mirrors already present a view of the world very close to this anyway. -- Jecel

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 March 1996