Self-interest December 2009

self-interest@lists.selflanguage.org

8 participants
5 discussions

Some questions about Self (Transcript, Modules, Browsing Subobjects, Debugging, defaultBehavior)
by shanenbe 02 Feb '10

02 Feb '10

Hi all, I am relatively new in Self and have a bunch of questions (I am using Self 4.4 alpha2/Linux). 1. Transcript I wanted to implement something such as Transcript - but I saw that there is already such an object (but I cannot open it). transcript copy show. ends with a "depth not found"-error. Is it maybe a restriction of my linux, or does transcript really has this problem? 2. Modules Is there an easy way to see what elements are in a module? For examples, I added a module "shChanges" which I open via "modules shChanges". Can I see somehow what objects exist in this module? 3. Subobjects of a certain object Is there a way to see what objects are subobjects of a given one? For example, if I have an outliner for "defaultBehavior". Is there a way to get a list of all object which use defaultBehavior as parent? 4. Debugging Is there a way to evaluate an object which is shown in the debugger. For example, if I have a error in a statement such as doPrint: myObject doSomething and I want to inspect myObject. Does the debugger provide such a thing? Can I evaluate a statement using the context of the debugger? 5. Design decision with defaultBehavior I am slightly confused about the design decision that not every object has defaultBehavior as super object. Is this intended in that way or rather "an accident"? The reason why it confuses me is, that i cannot use a new created object within a collection (since slots for e.g. comparing objects are not available). -Stefan

8 17

Exception handling / Fail blocks?
by Stefan Hanenberg 28 Dec '09

28 Dec '09

Hi all, how can I handle an exception throws by the message 'error'. I find some references to fail blocks, but I have so far not seen any in action. Please, can someone guide me to some code with some exception handling (or fail-blocks)? -Stefan

1 0

Self issue tracker now on Lighthouse
by Russell Allen 21 Dec '09

21 Dec '09

Hi all, After looking through some of the issue tracking sites that people kindly pointed me to, I've set up a trial on Lighthouse. It is at: http://self.lighthouseapp.com You can see from the information there that the current plan is to issue a new release in late January, and a hopefully final Self 4.4 on Linux and Mac in late February. We can then move on to more exiting improvements! I encourage everyone to add issues etc. Best wishes, Russell

1 0

Re: [self-interest] A question about Self encapsulation
by Russell Allen 18 Dec '09

18 Dec '09

I haven't tried it, but if the availability of mirrors could be restricted then objects should be able to protect/encapsulate other objects either by making the slot name something unguessable or by having the object only referred to in a method... On Thu, 17 Dec 2009 16:45:58 -0200, "Jecel Assumpcao Jr" <jecel(a)merlintec.com> wrote: > Takuro Ikejiri wrote: > >> according to this page, >> "The distinction between public and private is purely for documentation. >> Earlier versions of Self enforced privacy (allowing only sends to self >> to locate private slots) but this scheme was found to be unworkable." >> >> My question is "what is unworkable about Self encapsulation ?". > > There was a package of features in Self 1 and 2 that were removed from > Self 3. They were: > - slot privacy declaration > - parent priority > - the "tie breaker" rule > > With parent priorities, inheritance could be used for such things as > local name spaces for an object's slots and controlled multiple > inheritance. With lots of small objects in a complex inheriantce graph, > the tie breaker rule was needed to keep the number of conflicts that had > to be manually solved by reorganizing the code as small as possible. The > privacy declarations fit in very well with the scheme, though as Russell > has pointed out they weren't much of a security feature. > > As programs grew it became more common for these features to cause a > different slot to be found by the lookup algorithm than what the > programmer expected. For Self 3 a far simpler scheme was adopted: all > parents with the same priority with multiple inheritance used in very > limitd ways and object annotations added to provide namespaces within > objects. It would have been possible to keep enforcing the privacy > declarations even with these changes but it was decided that they were > probably not the best solution and so the problem should be postponed > until a good solution could be found. They were kept as part of the > syntax and were reflected in the new GUI (public slots have bold names). > > A variation of Self with subjective programming, called "Us", was > designed and a crude prototype was implemented in Self. That was > considered to be the proper solution to object encapsulation: > > http://portal.acm.org/citation.cfm?id=246311 > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.56.7535 > http://www.mip.sdu.dk/~bnj/library/Us_Ungar.pdf > >> I also read a paper ( parents are shared parts of objects: >> Inheritance and encapsulation in SELF,1991), >> and learned about inheritance-based encapsulation. >> I think this approach is not good because an encapsulated module >> cannot prohibit access from outside >> (because an object gain access to the module by becoming a child of >> the module). > > That paper talks about Self 1. The problem you describe is very serious > and couldn't be solved by just patching the original model. Self 3 > wasn't a solution, but like I said above just a "rip out what didn't > work out so well until we can think of something that will work" kind of > thing. Us was the solution, but it isn't available so we are stuck in > the Self 3 model for now. > > -- Jecel

2 1

A question about Self encapsulation
by takuro ikejiri 17 Dec '09

17 Dec '09

Hi all, I am a university student and interested in prototype-base language. I have a question: http://research.sun.com/self/release_4.0/Self-4.0/Tutorial/Language/Finishi… according to this page, "The distinction between public and private is purely for documentation. Earlier versions of Self enforced privacy (allowing only sends to self to locate private slots) but this scheme was found to be unworkable." My question is "what is unworkable about Self encapsulation ?". I also read a paper ( parents are shared parts of objects: Inheritance and encapsulation in SELF,1991), and learned about inheritance-based encapsulation. I think this approach is not good because an encapsulated module cannot prohibit access from outside (because an object gain access to the module by becoming a child of the module). I'd appreciate it if you could answer this question. Thanks in advance.

3 2

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 December 2009