Self-interest January 1995

self-interest@lists.selflanguage.org

10 participants
12 discussions

ambiguous inheritance question
by Ivan Moore 03 Feb '95

03 Feb '95

Dear Self interest group, What are peoples opinions on the following: given an inheritance hierarchy as below: A / \ B C \ / D where B and C are parents of D, and A is the parent of B and C, If A defines slot m, and B defines its own version of slot m, if you send D the message m, you get an ambiguous selector error (as expected). How about if D got the m in B, because it does override the one in A, after-all. What I mean is that the m in B overrides the very same slot m that D inherits via C. If it was a different m that it was overriding I'd be totally happy with an ambiguous selector error. What do you think? Would the proposed scheme invite obscure bugs? Would it be difficult to understand? You may think that this sort of situation doesn't occur often enough to be a problem - maybe true - but dispite that, what do you think? Ivan.

3 2

Re: ambiguous inheritance question
by chambers＠cs.washington.edu 31 Jan '95

31 Jan '95

> From Bay.Chang(a)Eng.Sun.COM Tue Jan 31 20:42:12 1995 > Content-Type> : > text> > From: Ivan Moore <ivan(a)cs.man.ac.uk> > To: self-interest(a)self.stanford.edu > Subject: ambiguous inheritance question > Date: Wed, 25 Jan 95 19:26:16 GMT > > > Dear Self interest group, > > What are peoples opinions on the following: > > given an inheritance hierarchy as below: > > A > / \ > B C > \ / > D > > where B and C are parents of D, and A is the parent of B and C, > > If A defines slot m, and B defines its own version of slot m, if you send D > the message m, you get an ambiguous selector error (as expected). > > How about if D got the m in B, because it does override the one in A, > after-all. What I mean is that the m in B overrides the very same slot m that D > inherits via C. If it was a different m that it was overriding I'd be totally > happy with an ambiguous selector error. > > What do you think? Would the proposed scheme invite obscure bugs? Would it > be difficult to understand? You may think that this sort of situation doesn't > occur often enough to be a problem - maybe true - but dispite that, what do > you think? > > Ivan. > > I proposed such a "partial-order-based" MI overriding rule for Self a long time ago. I think the argument against it is that you no longer can view each parent (B & C) separately, but only in combination. I.e., to understand method lookup for D, you have to examine D's entire inheritance hierarchy; you can't just send lookup to each of the parents independently and then combine the results in a simple way. But I still like this more global semantics for MI, and I've included it in the Cecil language I've been working on. We've written 50K lines of Cecil code in our Cecil optimizing compiler, and I think our experience with this MI semantics has been quite favorable. At least, it's always made sense to me how method overriding worked, and I can't recall ever being bitten by a bug as a result of this semantics. -- Craig

1 0

Re: ambiguous inheritance question
by Randall.Smith＠Eng.Sun.COM 31 Jan '95

31 Jan '95

> > given an inheritance hierarchy as below: > > A > / \ > B C > \ / > D > > where B and C are parents of D, and A is the parent of B and C, > > If A defines slot m, and B defines its own version of slot m, if you send D > the message m, you get an ambiguous selector error (as expected). > > How about if D got the m in B, because it does override the one in A, > after-all. What I mean is that the m in B overrides the very same slot m that D > inherits via C. If it was a different m that it was overriding I'd be totally > happy with an ambiguous selector error. > > What do you think? Would the proposed scheme invite obscure bugs? Would it > be difficult to understand? You may think that this sort of situation doesn't > occur often enough to be a problem - maybe true - but dispite that, what do > you think? > > Ivan. > > I believe this is what we call "unordered up to (but not including) join" semantics. I think Craig Chambers, who was with the Self group at the time we were rethinking MI, was an advocate for putting this style of MI in Self.(comment Craig?) It's something we talked about, and it does have the advantage of allowing many cases (but not all cases, I think) of "data parents." There are still other concerns about data parents ... Self used to have them many years ago, but they were kind of nice in some ways. Anyway, the thinking was more on the side of radical simplification: making MI as easy as possible to understand. However unordered up to join is maybe not all THAT complicated, and because it allows this useful data parent thing, maybe it is a good idea. Instead of data parents, today we "copy down" at creation time, and that yields its own set of complications. Interesting that you hit upon this idea! --Randy P.S.: In unorderd up to join, this below would be an error, whereas in the old days, B and C could be given different priorities, and therefore data parents, who often appear in graphs like this, were easier to support. A(m) / | / | / | B(m) C(m) | / | / | / | / D

2 1

Is there a self port for Linux ?
by Reto Kramer 23 Jan '95

23 Jan '95

I'd like to learn self but I can't afford a sun box. Since there is no HP-UX port (at least a few month ago, there wasn't), I can't do it in the office either. Is there a port for Linux (I am also happy with a slow thing) ? Reto ---- ESEC SA Reto Kramer Dept. Autoline Hinterbergstr. 32 CH-6330 Cham Switzerland email: {kramer(a)acm.org, reto.kramer(a)al.esec.ch} tel (direct): +41 42 44 52 84 fax : +41 42 41 64 84

2 1

Re(2): when should sends be virtual?
by David Ungar 20 Jan '95

20 Jan '95

Have you studied Henry Liebermann's paper on prototypes and delegation in OOPSLA'86? I believe it was the first to use delegation in this area and that it did define it to be what C++'ers would call "virtual". If this is correct, then it can be very confusing to use the word "delegation" is a CS context to mean "just do this and don't bother me again". After all, that is what "message sending" and "forwarding" mean. So, please read this paper, and if you agree with the above, you might want to either avoid the word, or use it only in its original technical sense, otherwise you can confuse people. There is also a paper called "Parents are Shared Parts of Objects; A Shared View of Sharing" (or something like that) that we published a while back in a special issue of the Journal of Lisp and Functional Programming. I think it is available by ftp from self.stanford.edu. Although it was written a while ago, I think that its discussion of this issue is a better explanation of at least my position than I could convey in e-mail. I suspect that much has already been said on both sides of this one-- you might enjoy reading more of the many paper on this topic. - Dave ------ From: Rainer Blome, Wed, Jan 18, 1995 ------ hi again. these are some remarks that i thoght to be of general interest, taken from my reply to a mail from guenter kniesel, so they may sometimes appear to be somewhat out of context. (my original posting included a rather serious flaw if one read it literally since accidentally wrote `ancestors' instead of `descendants'. see below.) no quote if rom my reply, single quote `> 'is from guenter, double quote `>> ' is from my original message. >> who is the parent of the method? what i meant is: if some selector is not found in the activation record, which is the object where the lookup will continue (`method parent')? > This is the very semantics of the notion of "self" / "this" / "current". what do you mean with `very semantics'? here's a little story: (respective meanings of metaphors in parentheses) imagine Frank (object) in some work hierarchy (delegation chain) being asked to foo (receives unary message). he doesn't know how to foo (lookup failed) and delegates this to his superior Sabine (parent). Sabine knows how to foo (lookup succeeded). she gets the scrap of paper with the instructions (code) and follows them: the first line says "bar!" (exclamation point instead of full stop used for clarity) aha, this is an instruction for herself (huh?). END OF STORY in self as it is, this is to say that message bar is to be sent to implicit self. but now, who should execute these instructions? Sabine? or should she lend that scrap of paper to Frank so he may do what he was asked to do? then what does delegation mean, actually? in the `real' world, `to delegate' surely means to have the other guy actually do it, not just tell one how to do it. mommy, i don't know how to do this, will you do it for me, please? this is what a naive observer would expect self to work like. the current practice seems counterintuitive to me. it looks more like the `shared slots' way of sharing (inheriting) behavior, as if all the ancestor's slots were directly present in an object (except the overridden ones). >> and it is 'non-virtual' when lookup starts in y, being the holder of >> bar. ... when i said `it is non-virtual', i meant `i call it non-virtual'. >> ... in self, this is called an 'undirected resend'. > So explicit undirected resends only say where to ... restart the search. true. undirected resend is indeed not what i called non-virtual. non-virtual would mean that self is set to y resp. Sabine resp. to the holder of any method that sends to implicit self. this kind of send semantics is missing in self, if i am not missing anything. it might be simulated by some delegation primitive though. >> shouldn't it always have to be made explicit when the result of a lookup >> cannot be determined by the sender? dynamic inheritance set aside, a >> method 'knows' the behavior (of its ancestors) it can rely on when doing >> a non-virtual send. it seems like good style to me to make it explicit >> when one relies on things that are uncertain. of course one cannot surely determine the result of a lookup beforehand, that's the good thing about dynamic inheritance. but if y holds methods foo and frob, and the programmer wants to invoke frob from foo and is sure that she wants the frob in y and nowhere else, she can't enforce it in self! (except when she knows that y may be reached by sending message `y' to self, that'd be even messier.) >> making non-virtual sends the default would also give an easy answer >> for a question discussed here some weeks ago: how to determine what >> behavior some objects rely on their childs to supply it. simply look >> for virtual sends instead of having to check whether a send to self is >> already implemented in the object or its ancestors. > I don't see how looking at the code of children can help to determine > what _parent_ objects expect from their descendants. The children > only show what _they_ expect from their parents. OOPS, i meant descendants, not ancestors. >> did anybody ever see a treatise about where and when it should be >> specified that a message send should be virtual? at the send site? > Some languages / type systems specify "fixed" types, i.e. variables > that cannot be substituted by values of subtypes. Here static binding > can be always done. If you are deeply interested I can provide you > some references. no thanks, my eyes would hurt if i saw that ... ;-) >> or at the declaration/implementation of a method? > That is being done in Simula, Beta, C++, ... *clonk* (simula and beta just dropped in interestingness coz this means they are statically typed, right?) to summarize once again: the decision whether a send should be virtual should be made at the send site. maybe this demands having two of these global object-references, `holder' and `receiver of last message to non-self'. as i see it, what we mean by `holder' is closer to the common-sense meaning of `self' than what `self' currently means in Self (sic!). another issue is concurrency/asynchronous sends: easy with the holder-is-self semantics (except for actual synchronization problems like access); with the `shared methods' semantics, it becomes impossible when the unit of concurrency is the object. <a href="http://namu19.gwdg.de/rblome">Rainer Blome</a>

1 0

Re: when should sends be virtual?
by Guenter Kniesel 19 Jan '95

19 Jan '95

<rainer(a)physik3.gwdg.de> wrote: > >> who is the parent of the method? > what i meant is: if some selector is not found in the activation record, > which is the object where the lookup will continue (`method parent')? Page 5 of the Self 3.0 manual says: "If a slot contains a method...: * The method object is cloned, creating a new method activation object... * The clone's self parent slot is initialized to the receiver of the message. * ..." So the lookup will continue in the message receiver. In the case of self sends / implicit receiver messages this will be the object currently denoted by "self". In your next example, "bar" will be executed in the context of "Frank". > imagine Frank (object) in some work hierarchy (delegation > chain) being asked to foo (receives unary message). he doesn't know how > to foo (lookup failed) and delegates this to his superior Sabine (parent). > Sabine knows how to foo (lookup succeeded). she gets the scrap of paper > with the instructions (code) and follows them: the first line says > "bar!" (exclamation point instead of full stop used for clarity) > aha, this is an instruction for herself (huh?). END OF STORY > > in self as it is, this is to say that message bar is to be sent to implicit > self. but now, who should execute these instructions? Sabine? or should > she lend that scrap of paper to Frank so he may do what he was asked to do? Neither one. If you prefer to talk in metaphors, then my understanding is that the (clone of the) scrap of paper will execute the instructions. But it will not do it on his own - e.g. it will look at how Frank would "bar". > then what does delegation mean, actually? in the `real' world, `to > delegate' surely means to have the other guy actually do it, not just tell > one how to do it. mommy, i don't know how to do this, will you do it for > me, please? this is what a naive observer would expect self to work like. In my understanding, the mommy example is not delegation but simply asking for help. Whatever you asked from her, your mommy will do it _as SHE knows best_. The best intuitive explanation of (object-oriented) delegation that I found until now is that when I delegate a task to someone, I expect her to do something _on my behalf_ that is, I expect that SHE does it MY WAY. So regardless whether Sabine or the scrap of paper executes "bar" they should do it the same way as Frank would. For that, they need to check what Frank would do. That's exactly what is achieved by SELF. > to summarize once again: > the decision whether a send should be virtual > should be made at the send site. maybe this demands having two of these > global object-references, `holder' and `receiver of last message to non-self'. > as i see it, what we mean by `holder' is closer to the common-sense meaning > of `self' than what `self' currently means in Self (sic!). As a student I worked in an ESPRIT I project called EPSILON, which implemented a knowledge representation framework that extended logic programming with some object-oriented concepts. EPSILON allowed different kinds of object-based inheritance. The most primitive one was called "consultance" (in the vein of the previous example we could also call it "ask for help") and its semantics was simply that messages, m, that had no local definition where automatically resent to a parent object, p, that posessed a definition. The resent message was then solved in the context of that parent. Put more technically, following "consultance" links changed the self variable, such that subsequent sends to self during the execution of m where directed to p. You seem to suggest a more fine grained version of this concept, that allows to specify at every send site whether "self" should be reset to the parent in which the lookup was successful. So "self m" (resp. "m") does not change self, whereas "holder m" starts the lookup for m in the current self object but changes self to the object in which the lookup was successful (before executing the found code). Guenter.

1 0

Re: when should sends be virtual?
by Guenter Kniesel 19 Jan '95

19 Jan '95

rainer wrote: > randy wrote: > > We were trying to support maximum flexibility. ... > > then you defined flexibility as possibilities for the client (child) to > change the behavior of the server (ancestor). (would YOU want to allow your > child to alter your behavior? ;-) No, the child does not alter my behaviour resp. the behaviour of its ancestor. If a message is addressed to me / the ancestor then whatever the child defines has no influence. The child can only modify what it _inherited_ from me and that's the way it should be! I hope that my son will learn to behave differently from me in many situations. Unfortunately, that will not automatically change the way I behave. > > ... Why would you want to say > > to a child "you cannot specialize the use of `foo' in this method, even > > if you want to"? ... > > because of reliability reasons, of course. > ("in a delegation chain, any object may screw up ancestors' semantics." ^^^^^ Ideally one should only care about the protocoll of the _direct_ ancestor(s) not whether it is implemented in the object itself or inherited from others. The need to give the programmer a quick overview of all the methods valid for a particular object is a reason for improving the development environment, not for changing the language design.

1 0

when should sends be virtual?
by rainer＠physik3.gwdg.de 19 Jan '95

19 Jan '95

hi! i am wondering whether there are any "fundamental" arguments in favor of or against the convention in self that all sends to self are 'virtual' by default. what i mean is this: imagine object x receives message foo and the lookup finds a corresponding method in ancestor y. now this method foo sends the message bar to self. who is self, where does the lookup start (after searching the local (method) slots), who is the pareent of the method? this is a question, i am unable to determine that decidedly from the manuals, i can't run self here. i call the send 'virtual' when the lookup starts in x, being the receiver of the last non-self send (e.g. foo). this is the default with self, right? and it is 'non-virtual' when lookup starts in y, being the holder of bar. in self, this is called an 'undirected resend'. since one can always deliberately decide which way to use, it might just be a matter of convenience which way is to be the default. but it might be a matter of good programming style as well: shouldn't it always have to be made explicit when the result of a lookup cannot be determined by the sender? dynamic inheritance set aside, a method 'knows' the behavior (of its ancestors) it can rely on when doing a non-virtual send. it seems like good style to me to make it explicit when one relies on things that are uncertain. making non-virtual sends the default would also give an easy answer for a question discussed here some weeks ago: how to determine what behavior some objects rely on their childs to supply it. simply look for virtual sends instead of having to check whether a send to self is already implemented in the object or its ancestors. there are more possibilities, but only for statically compiled languages, i think: actually, one might not be able to deliberately decide which way to use because it has been defined one way at the time of class-declaration. this is the case with c++ for example. did anybody ever see a treatise about where and when it should be specified that a message send should be virtual? at the send site? or at the declaration/implementation of a method? ever seen one of these answered? greetings, rainer

2 2

Re: when should sends be virtual?
by Randall.Smith＠Eng.Sun.COM 19 Jan '95

19 Jan '95

> i am wondering whether there are any "fundamental" arguments in > favor of or against the convention in self that all sends to self > are 'virtual' by default. > > what i mean is this: > > imagine object x receives message foo and the lookup finds a > corresponding method in ancestor y. now this method foo sends the > message bar to self. who is self, where does the lookup start > (after searching the local (method) slots), who is the pareent of > the method? this is a question, i am unable to determine that > decidedly from the manuals, i can't run self here. > > i call the send 'virtual' when the lookup starts in x, being the > receiver of the last non-self send (e.g. foo). this is the default > with self, right? > That is correct (assuming I understand what you are saying) > and it is 'non-virtual' when lookup starts in y, being the holder of > bar. in self, this is called an 'undirected resend'. > > since one can always deliberately decide which way to use, it might > just be a matter of convenience which way is to be the default. but > it might be a matter of good programming style as well: shouldn't it > always have to be made explicit when the result of a lookup cannot > be determined by the sender? dynamic inheritance set aside, a > method 'knows' the behavior (of its ancestors) it can rely on when > doing a non-virtual send. it seems like good style to me to make it > explicit when one relies on things that are uncertain. > > making non-virtual sends the default would also give an easy answer > for a question discussed here some weeks ago: how to determine what > behavior some objects rely on their childs to supply it. simply > look for virtual sends instead of having to check whether a send to > self is already implemented in the object or its ancestors. > > there are more possibilities, but only for statically compiled > languages, i think: actually, one might not be able to deliberately > decide which way to use because it has been defined one way at the > time of class-declaration. this is the case with c++ for example. > > did anybody ever see a treatise about where and when it should be > specified that a message send should be virtual? at the send site? > or at the declaration/implementation of a method? > ever seen one of these answered? > > greetings, rainer > Thanks for an interesting question! I have had similar discussions before though only briefly. I underatnd some of the motivation or making "non-virtuals" the default. Here is what we were thinking in the original design of Self: We were trying to support maximum flexibility. Why would you want to say to a child "you cannot specialize the use of 'foo' in this method, even if you want to"? So we used "full virtuals" for everything we could. If we could trust the method designer to know best and for all time that something should never be specialized, then using non-virtuals by default might make sense. My belief is that such trust is unwise. Most created things can satisfy more than their creator's original goals. --Randy

3 2

Re: when should sends be virtual?
by Randall.Smith＠Eng.Sun.COM 19 Jan '95

19 Jan '95

Rainer... When I participate in e-mail dscussions like this, I am aware of a spectrum of choices. The bombastic assertion is at one end and the analytic, balanced discussion at the other. I thought last time I would try the bombastic assertion just to see what happened. I think I blew it. Anyway, all the observations you make (well, those I understand) about the situation are true, and each problem will bite you to various degrees. I think the only way to tell how bad each problem is is to try programming in Self for a good spell, then make up your mind. Here are some commnets based on my experience. Of course I probably have my biaes... > then you defined flexibility as possibilities for the client (child) to > change the behavior of the server (ancestor). (would YOU want to allow your > child to alter your behavior? ;-) I understand what you are saying, but in practice, a child very rarely changes the behavior of a parent in Self. Even though most of the code we run in Self is borrowed from an object for use in its decendants, the code-donor parent does not get its behavior changed when its code is used by the child, unless there is state in the parent that can be changed. This is in practice possible, and in fact when you have class-variable like slot usage in Self, this does happen. Class-variables tend to be few and I guess their semantics must be fairly well understood, because we have not had a frequent problem of children accidentally corrupting class variables. We *have* had occassional problems of "corrupted prototypes" which is somewhat different but related to what you are saying. > ...another definition might be > freedom to write code without breaking existing code. We do have to figure out how to debug our code and that is dificult when you are inheriting much other code. Again, it is very rare for some object to actually break a parent or a sibling. > > when all sends have virtual semantics, the author of a descendant has to > take care to not accidentally override ANY of the possibly large number of > selectors that its ancestors implement and use (she may of course > deliberately do so). > Actually, I can understand why you say this, but in practice name space collisions do not turn out to be a major problem for some reason. Perhaps it is because short names are well known and therefore avoided, and obscure functionality tends to get very verbose names, so colision probablity is very low. Perhaps other Self programmers would report a different experience... > somtimes flexibility adds to utility, sometimes it doesn't (see assembler > or c). the protocol supported by a parent (and potentially overridden by > the child) is not obvious. you have to use some tool to keep track of > that, this again adds to development tool fatware. and it lowers > productivity, because the programmer has to do something (check for name > clashes) when he wants to do nothing (not override anything). > as stated above, no extra tools seem to be needed, but this is only based on my own opinion of my own experience. Let's put it this way..we are always adding new gizmos to make programming easier and more fun in Self, but none of them have had to do with this unintention name reuse problem. > the programmer knows if she uses existing (ancestor) protocol or demands > `most specialized' (descendant) protocol. to really rely on this > knowledge, the two variants must be explicitly coded. as i see it, > ancestor responsibility is more common than descendant responsibility. > > (anyone has any statistics on this question? > i strongly suspect that this depends on the > language being used and previous experience > with other languages.) > > therefore it'd be more convenient to mark virtual sends than > non-virtual ones. > I don't really understand the above point... > > > ... Why would you want to say > > to a child "you cannot specialize the use of `foo' in this method, even > > if you want to"? ... > > because of reliability reasons, of course. > ("in a delegation chain, any object may screw up ancestors' semantics." > AND > "objects in a delegation chain may have been implemented by different > programmers" > AND > "in every team of programmers, there's at least one bad programmer" > IMPLIES > ... well, this is of course NOT a valid chain of inference, but you see > the point :) > I can only tell you in my own experience, screwing up ancestors is not a major problem in Self, as I have stated before. Having different programmers IS a problem, because you have to understand what they mean in order to use their code. Inheriting from an object that was designed by someone else is undoubtedly even more difficult. I'm not sure it is really worse in Self, since you only normally override a few things in any language, including Self. Bad programmers might make this worse, but I am lucky enough to be working with the best! ;-) (politically smart comment there, eh?) > > > If we could trust the method designer to know best and for all time that > > something should never be specialized, then using non-virtuals by > > default might make sense. My belief is that such trust is unwise. > > since it is clear that "knowing best and for all" is next to impossible > that kind of trust would indeed be unwise. but trust IS necessary for > effective programming and unless the programmer explicitly states his > intentions, there is nothing to trust in (s.a.). > I'm missing the point there. Maybe you want extra declarative semantics of some sort? > > > ... Most > > created things can satisfy more than their creator's original goals. > > true. > > > another aspect of virtual methods being the default is speed. considering > this, i don't understand why it is as it is when one of the original design > goals was speed. Speed was definitely NOT one of the original design goals ! In fact, the impossibility of using an interpreter to get any reasonable performance out of Self semantics was the motivation for novel implementation techniques. > (question: how efficient are resends? less than > self-sends when self is the holder?) > You have to ask one of the clever implementation type guys. > > so far, i'm convinced virtual sends should not be the default. > Bummer! You might like something like Beta, which lets the ancestor designer specify when to run code in a child by use of "inner." Perhaps my bias is towards rapid prototyping. When I compare with my years of Smalltalk experience, which does not allow you to override instance variable assignment, I feel more productive in Self. It is a simple matter of greater flexibility. It is noticably easier to change my mind about a design. The corrupted prototype problem does occur in Self and not Smalltalk. We are working on ways to mitigate against that. Even so, it is not a major problem, but significant enough to merit attention. Greater use of Self over longer periods might show up other problems. We currently are working without privacy semantics, for example. As in the simplest, "pure" Self. This may turn out to create awkwardly "wide" interfaces that are difficult to maintain. However, I can't say it has been a major problem yet, perhaps because we have hints in the programming environment about intented use. But as time goes by this problem or others could appear(?). --Randy

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 January 1995