Loading ...
Sorry, an error occurred while loading the content.

Multiple inheritance

Expand Messages
  • std70
    Hello! I m Diego, a very beginner in self. Two questions: - Nowadays, has Self multiple inheritance? - If not, why Self lost this feature? Thanks Diego
    Message 1 of 16 , Nov 3, 2005
    • 0 Attachment
      Hello!
      I'm Diego, a very beginner in self.

      Two questions:
      - Nowadays, has Self multiple inheritance?
      - If not, why Self lost this feature?

      Thanks
      Diego
    • J. Baltasar Garcia Perez-Schofield
      Hi, Diego ! ... I think Self has never lost its capabilities for multiple inheritance. All slots ending with a star * will be considered parent attributes.
      Message 2 of 16 , Nov 4, 2005
      • 0 Attachment
        Hi, Diego !

        > I'm Diego, a very beginner in self.
        > Two questions:
        > - Nowadays, has Self multiple inheritance?
        > - If not, why Self lost this feature?

        I think Self has never lost its capabilities for multiple inheritance.
        All slots ending with a star '*' will be considered parent attributes.

        Which finally lost its position in Self was the tie-breaker rule,
        proposing a smart strategy in order to choose which "inheritance path"
        to follow once it is discovered that a message cannot be satisfied in a
        given object.

        Salud !

        Baltasar

        --
        PBC -- J. Baltasar García Perez-Schofield
        jbgarcia en uvigo de es http://webs.uvigo.es/jbgarcia/
        Dep. Informática, Universidad de Vigo, España (Spain)
      • Diego
        Hola Baltasar! Thanx for the answer. ... Could you give me some tip for searching? I dont understand this point :-(. If Self support multiple inheritance, how
        Message 3 of 16 , Nov 4, 2005
        • 0 Attachment
          Hola Baltasar!
          Thanx for the answer.

          >Which finally lost its position in Self was the
          >tie-breaker rule,
          >proposing a smart strategy in order to choose
          >which "inheritance path"
          >to follow once it is discovered that a message
          >cannot be satisfied in a
          >given object.

          Could you give me some tip for searching? I'dont
          understand this point :-(.
          If Self support multiple inheritance, how do it
          manage the name clashes problem?

          Regards!
          Diego



          __________________________________
          Yahoo! FareChase: Search multiple travel sites in one click.
          http://farechase.yahoo.com
        • J. Baltasar Garcia Perez-Schofield
          Hi ! ... You can check the Self web site out for papers (publications section): http://research.sun.com/self/ ... It doesn t have to do, because objects are
          Message 4 of 16 , Nov 4, 2005
          • 0 Attachment
            Hi !

            > Could you give me some tip for searching? I'dont
            > understand this point :-(.

            You can check the Self web site out for papers (publications section):

            http://research.sun.com/self/

            > If Self support multiple inheritance, how do it
            > manage the name clashes problem?

            It doesn't have to do, because objects are not built by mixin their
            parents in the same structure.

            If you refer to two methods in different "paths of inheritance", then I
            suppose Self just begins with the first parent attribute until it finds
            the method it is looking for. So the first one found wins over the
            others.

            Salud !

            Baltasar

            --
            PBC -- J. Baltasar García Perez-Schofield
            jbgarcia en uvigo de es http://webs.uvigo.es/jbgarcia/
            Dep. Informática, Universidad de Vigo, España (Spain)
          • Ian Woollard
            ... If you get name clash (two different methods that match the send) you get a traceback. Name clashes can be resolved manually by specifying the path IRC.
            Message 5 of 16 , Nov 4, 2005
            • 0 Attachment
              On 11/4/05, Diego <std70@...> wrote:
              > If Self support multiple inheritance, how do it
              > manage the name clashes problem?

              If you get name clash (two different methods that match the send) you
              get a traceback.

              Name clashes can be resolved manually by specifying the path IRC.

              > Regards!
              > Diego

              --
              -Ian Woollard

              "People are brilliantly stupid, and stupidly brilliant"-Robin Abrahams
            • Jecel Assumpcao Jr
              J. Baltasar Garcia Perez-Schofield wrote on Fri, 04 Nov 2005 20:30:06 +0100 ... This would be a depth first search for slots, which as Ian wrote in another
              Message 6 of 16 , Nov 5, 2005
              • 0 Attachment
                "J. Baltasar Garcia Perez-Schofield" wrote on Fri, 04 Nov 2005 20:30:06
                +0100
                > If you refer to two methods in different "paths of inheritance", then I
                > suppose Self just begins with the first parent attribute until it finds
                > the method it is looking for. So the first one found wins over the
                > others.

                This would be a "depth first" search for slots, which as Ian wrote in
                another message isn't how things are done in Self.

                Self 1.0 and 2.0 had these features:

                - parent priorities indicated by the number of "*" in the slot name.
                All parent slots of a given priority were searched together and only if
                no slot with that name was found were parents of the next lower priority
                searched

                - privacy declarations would hide certain slots from searches depending
                on which object had sent the message

                - the tie breaker rule was used when more than one slot with the same
                name were found even with the above two features. It selected one of the
                slots as the "right" one

                High priority mixins were used do divide up very large objects into
                smaller, named pieces.

                The main problem with this combination of features is that sometimes a
                slot would get selected as the "right" one which wasn't what you
                expected and this was particularly hard to debug.

                So in Self 3.0 we had these changes:

                - all parents have the same priority

                - privacy declarations are now only informative and have no effect on
                slot lookup

                - no more tie breaker rule, so as Ian said you get an "ambiguous send"
                error unless exactly one slot is found in a full search

                - object and slot annotations were introduced and this replaced
                inheritance as a way to divide large objects. It also added a lot of
                meta information that made the transporter possible

                Self has always had two kinds of resends (like "super" in Smalltalk):
                directed ones where you specify one parent to be search and undirected
                ones with the word "resend" instead of a parent name which indicates
                that all parents should be searched. Using the first kind you can work
                around duplicated slot names but in the general case you will have to
                refactor and/or rename things in your code to get it to work. In
                practice this has proved to be much more usable than the original
                automatic solution.

                -- Jecel
              • J. Baltasar Garcia Perez-Schofield
                Hi, Jecel ! Thank you for the info. However, ... So if a resend is performed, and all parents are searched ... is a depth lookup run or not ? Maybe a lookup
                Message 7 of 16 , Nov 7, 2005
                • 0 Attachment
                  Hi, Jecel !

                  Thank you for the info. However,


                  > Self has always had two kinds of resends (like "super" in Smalltalk):
                  > directed ones where you specify one parent to be search and undirected
                  > ones with the word "resend" instead of a parent name which indicates
                  > that all parents should be searched. Using the first kind you can work
                  > around duplicated slot names but in the general case you will have to
                  > refactor and/or rename things in your code to get it to work. In
                  > practice this has proved to be much more usable than the original
                  > automatic solution.

                  So if a "resend" is performed, and all parents are searched ... is a
                  depth lookup run or not ? Maybe a lookup in width ?

                  Salud !

                  Baltasar

                  --
                  PBC -- J. Baltasar García Perez-Schofield
                  jbgarcia en uvigo de es http://webs.uvigo.es/jbgarcia/
                  Dep. Informática, Universidad de Vigo, España (Spain)
                • Jecel Assumpcao Jr
                  ... Imagine we have an object like ( | parent* = traits clonable. sharedStuff* = mixins utilities. just an example - not in Self distribution moreStuff* =
                  Message 8 of 16 , Nov 7, 2005
                  • 0 Attachment
                    J. Baltasar Garcia Perez-Schofield wrote:
                    > > [Self has always had two kinds of resends]
                    >
                    > So if a "resend" is performed, and all parents are searched ... is a
                    > depth lookup run or not ? Maybe a lookup in width ?

                    Imagine we have an object like

                    ( | parent* = traits clonable.
                    sharedStuff* = mixins utilities. "just an example - not in Self
                    distribution"
                    moreStuff* = mixins graphics. "another example"
                    subElements <- list copyRemoveAll.
                    copy = ( | new |
                    new: resend.copy.
                    new subElements: subElements copy.
                    new ).
                    .....
                    | )

                    The "resend.copy" will do exactly the same (full) search that just
                    "copy" would have done except it will skip the local methods in the
                    object, which in this case is the very method doing the resend. That
                    means that any copy slots in "parent", "sharedStuff" and "moreStuff"
                    will be found and if there is more than one then a debugger will pop up.
                    Note that when I say a full search I don't mean that when a slot is
                    found in an object we keep going through its parents anyway, but that it
                    isn't a depth first search that would stop if the slot is found in
                    "sharedStuff" and wouldn't look in "moreStuff".

                    An alternative would be to replace "resend.copy" with "parent.copy" (for
                    example) and in that case a "copy" slot in either "sharedStuff" or in
                    "moreStuff" would not cause a problem. This is what Ian was talking
                    about when he said "name clashes can be resolved manually by specifying
                    the path".

                    Some people prefer a depth first search but that has a nasty side effect
                    that just changing the order of "sharedStuff" and "moreStuff" in the
                    above code could change its meaning! The way Self currently does things
                    allows you to not worry about this kind of thing.

                    -- Jecel
                  • J. Baltasar Garcia Perez-Schofield
                    Dear Jecel: Thank you again for your explanation. ... Yes, as super in Java. ... That s the point. But I suppose that this means that at runtime time, each
                    Message 9 of 16 , Nov 7, 2005
                    • 0 Attachment
                      Dear Jecel:

                      Thank you again for your explanation.


                      > ( | parent* = traits clonable.
                      > sharedStuff* = mixins utilities. "just an example - not in Self
                      > distribution"
                      > moreStuff* = mixins graphics. "another example"
                      > subElements <- list copyRemoveAll.
                      > copy = ( | new |
                      > new: resend.copy.
                      > new subElements: subElements copy.
                      > new ).
                      > .....
                      > | )
                      >
                      > The "resend.copy" will do exactly the same (full) search that just
                      > "copy" would have done except it will skip the local methods in the
                      > object, which in this case is the very method doing the resend.

                      Yes, as "super" in Java.

                      > That
                      > means that any copy slots in "parent", "sharedStuff" and "moreStuff"
                      > will be found and if there is more than one then a debugger will pop up.

                      That's the point.
                      But I suppose that this means that at runtime time, each time a
                      resend/"unqualified" message is sent, and more than one parent is found
                      for the receiver (and provided the receiver can't satisfy the message),
                      then all inheritance paths are explored in order to avoid the
                      possibility of finding more than one receiver (and show the debugger if
                      found).
                      This can't be limited to the first time because Self is dynamic, the
                      inheritance paths can change after a message is carried out due dynamic
                      inheritance. So Self has to do it every time, and I guess this is quite
                      expensive.
                      Or maybe I am missing something ?

                      The depth search is maybe problematic in some sceneries, but is
                      obviously better in the best case (the receiver is found in the first
                      inheritance path) and in the average case, though equal in the worst
                      case.

                      > An alternative would be to replace "resend.copy" with "parent.copy" (for
                      > example) and in that case a "copy" slot in either "sharedStuff" or in
                      > "moreStuff"

                      More or less as in C++ with "SomeParent::foo()", I guess. Yes, I
                      understand you can void any search by directly indicating the
                      "inheritance path" you are interested in.

                      > Some people prefer a depth first search but that has a nasty side effect
                      > that just changing the order of "sharedStuff" and "moreStuff" in the
                      > above code could change its meaning!

                      Absolutely.
                      However, is it likely to happen ?. I mean, if a programmer knows that
                      order of parents in the parent list (whatever syntax you choose) has a
                      meaning, would that programmer change the order of parents without
                      noticing ?

                      Regards,

                      Baltasar

                      --
                      PBC -- J. Baltasar García Perez-Schofield
                      jbgarcia en uvigo de es http://webs.uvigo.es/jbgarcia/
                      Dep. Informática, Universidad de Vigo, España (Spain)
                    • Michael Latta
                      This is the conceptual way it happens. Under the covers the VM generates something quite a bit more efficient. For each method invocation in the system it
                      Message 10 of 16 , Nov 7, 2005
                      • 0 Attachment
                        This is the conceptual way it happens. Under the covers the VM generates
                        something quite a bit more efficient.

                        For each method invocation in the system it points to a table that has a
                        mapping of object type to method body. This polymorphic cache is what makes
                        self based vms (HotSpot in java uses this) unique. In the case of Self the
                        "type" is computed dynamically based on the slots of the object and the
                        inherited behaviors. This web of dynamic typing is maintained under the
                        covers as objects are modified. For example if an object is cloned they
                        both have the same "type" until one has a behavior slot change. Once that
                        happens then a new type is created for the modified object. There is logic
                        in the system to reduce like types to the same type so there is limited type
                        fragmentation.

                        Michael


                        -----Original Message-----
                        From: self-interest@yahoogroups.com [mailto:self-interest@yahoogroups.com]
                        On Behalf Of J. Baltasar Garcia Perez-Schofield
                        Sent: Monday, November 07, 2005 8:34 AM
                        To: self-interest@yahoogroups.com
                        Subject: Re: [self-interest] resend (was: Multiple inheritance)


                        Dear Jecel:

                        Thank you again for your explanation.


                        > ( | parent* = traits clonable.
                        > sharedStuff* = mixins utilities. "just an example - not in Self
                        > distribution"
                        > moreStuff* = mixins graphics. "another example"
                        > subElements <- list copyRemoveAll.
                        > copy = ( | new |
                        > new: resend.copy.
                        > new subElements: subElements copy.
                        > new ).
                        > .....
                        > | )
                        >
                        > The "resend.copy" will do exactly the same (full) search that just
                        > "copy" would have done except it will skip the local methods in the
                        > object, which in this case is the very method doing the resend.

                        Yes, as "super" in Java.

                        > That
                        > means that any copy slots in "parent", "sharedStuff" and "moreStuff"
                        > will be found and if there is more than one then a debugger will pop up.

                        That's the point.
                        But I suppose that this means that at runtime time, each time a
                        resend/"unqualified" message is sent, and more than one parent is found
                        for the receiver (and provided the receiver can't satisfy the message),
                        then all inheritance paths are explored in order to avoid the
                        possibility of finding more than one receiver (and show the debugger if
                        found).
                        This can't be limited to the first time because Self is dynamic, the
                        inheritance paths can change after a message is carried out due dynamic
                        inheritance. So Self has to do it every time, and I guess this is quite
                        expensive.
                        Or maybe I am missing something ?

                        The depth search is maybe problematic in some sceneries, but is
                        obviously better in the best case (the receiver is found in the first
                        inheritance path) and in the average case, though equal in the worst
                        case.

                        > An alternative would be to replace "resend.copy" with "parent.copy" (for
                        > example) and in that case a "copy" slot in either "sharedStuff" or in
                        > "moreStuff"

                        More or less as in C++ with "SomeParent::foo()", I guess. Yes, I
                        understand you can void any search by directly indicating the
                        "inheritance path" you are interested in.

                        > Some people prefer a depth first search but that has a nasty side effect
                        > that just changing the order of "sharedStuff" and "moreStuff" in the
                        > above code could change its meaning!

                        Absolutely.
                        However, is it likely to happen ?. I mean, if a programmer knows
                        that
                        order of parents in the parent list (whatever syntax you choose) has a
                        meaning, would that programmer change the order of parents without
                        noticing ?

                        Regards,

                        Baltasar

                        --
                        PBC -- J. Baltasar García Perez-Schofield
                        jbgarcia en uvigo de es http://webs.uvigo.es/jbgarcia/
                        Dep. Informática, Universidad de Vigo, España (Spain)




                        Yahoo! Groups Links
                      • Jecel Assumpcao Jr
                        ... Correct except for the provided the receiver can t satisfy the message send the whole point of the resend is to skip any slots that the receiver might
                        Message 11 of 16 , Nov 7, 2005
                        • 0 Attachment
                          "J. Baltasar Garcia Perez-Schofield" wrote:
                          > > That
                          > > means that any copy slots in "parent", "sharedStuff" and "moreStuff"
                          > > will be found and if there is more than one then a debugger will pop up.
                          >
                          > That's the point.
                          > But I suppose that this means that at runtime time, each time a
                          > resend/"unqualified" message is sent, and more than one parent is found
                          > for the receiver (and provided the receiver can't satisfy the message),
                          > then all inheritance paths are explored in order to avoid the
                          > possibility of finding more than one receiver (and show the debugger if
                          > found).

                          Correct except for the "provided the receiver can't satisfy the message"
                          send the whole point of the resend is to skip any slots that the
                          receiver might have with that name.

                          > This can't be limited to the first time because Self is dynamic, the
                          > inheritance paths can change after a message is carried out due dynamic
                          > inheritance. So Self has to do it every time, and I guess this is quite
                          > expensive.
                          > Or maybe I am missing something ?

                          Michael Latta mentioned PICs and maps and other virtual machine tricks,
                          but I suppose that is what you mean by "the first time". Note that in my
                          example all three parents were constant slots. And probably their
                          parents too and so on. In such cases you can be sure that nothing will
                          change between the first and second times.

                          If one of the parents had an associated assignment slot then you would
                          be correct: a lookup would have to be repeated on each message send. But
                          in practice such dynamic inheritance is rarely used. I actually came up
                          with a way to greatly speed up this situation but it didn't seem worth
                          the effort. And I eliminated this feature entirely from my own Neo
                          Smalltalk design.

                          > The depth search is maybe problematic in some sceneries, but is
                          > obviously better in the best case (the receiver is found in the first
                          > inheritance path) and in the average case, though equal in the worst
                          > case.

                          You should first find out how much run time is being "wasted" on look up
                          before trying to make it faster. On page 18 of Urs Hölzle's thesis we
                          have that the cost of a inline cache miss is 250 clocks and the cost of
                          a hit is 9 clocks. The miss rate was from 0.62% to 6.66% in the
                          benchmark programs. So making lookup twice as fast would speed up sends
                          by 8 to 50% (supposing the whole 250 clocks is look up, which isn't
                          true).

                          > > Some people prefer a depth first search but that has a nasty side effect
                          > > that just changing the order of "sharedStuff" and "moreStuff" in the
                          > > above code could change its meaning!
                          >
                          > Absolutely.
                          > However, is it likely to happen ?. I mean, if a programmer knows that
                          > order of parents in the parent list (whatever syntax you choose) has a
                          > meaning, would that programmer change the order of parents without
                          > noticing ?

                          As Self currently is this would be very likely since you add the slots
                          graphically and they are shown in alphabetical order. But for some
                          scripting language this might be an interesting option. In early
                          versions of Self/R I did have a depth first search exactly as you
                          suggest but around the time I changed the name to Neo Smalltalk I
                          decided to get rid of parents entirely and make the programmers manually
                          order the "facets" which make up an object. The "tie breaker rule"
                          problems in early Self have made me avoid automatic solutions as much as
                          possible.

                          -- Jecel
                        • J. Baltasar Garcia Perez-Schofield
                          Hello ! ... Mmmm ... note I wrote resend/unqualified messages: as far as I understood, resend.copy and copy would behave the same but for the lookup in
                          Message 12 of 16 , Nov 7, 2005
                          • 0 Attachment
                            Hello !


                            > > That's the point.
                            > > But I suppose that this means that at runtime time, each time a
                            > > resend/"unqualified" message is sent, and more than one parent is found
                            > > for the receiver (and provided the receiver can't satisfy the message),
                            > > then all inheritance paths are explored in order to avoid the
                            > > possibility of finding more than one receiver (and show the debugger if
                            > > found).
                            >
                            > Correct except for the "provided the receiver can't satisfy the message"
                            > send the whole point of the resend is to skip any slots that the
                            > receiver might have with that name.

                            Mmmm ... note I wrote resend/unqualified messages: as far as I
                            understood, "resend.copy" and "copy" would behave the same but for the
                            lookup in "self" which would happend in the second case but not in the
                            first one.

                            > Michael Latta mentioned PICs and maps and other virtual machine tricks,
                            > but I suppose that is what you mean by "the first time". Note that in my
                            > example all three parents were constant slots. And probably their
                            > parents too and so on. In such cases you can be sure that nothing will
                            > change between the first and second times.

                            I see. They are constant slots because they don't have an assignment
                            slot.

                            > If one of the parents had an associated assignment slot then you would
                            > be correct: a lookup would have to be repeated on each message send. But
                            > in practice such dynamic inheritance is rarely used. I actually came up
                            > with a way to greatly speed up this situation but it didn't seem worth
                            > the effort. And I eliminated this feature entirely from my own Neo
                            > Smalltalk design.

                            I'm very interested. My own virtual machine assumes that parent
                            attributes can be changed anytime (not currently, sadly).

                            http://trevinca.ei.uvigo.es/~jgarcia/TO/zero/

                            So maybe you could explain what exactly you thought as a solution.
                            Although I am not working in that part of the VM, my first design to
                            overcome this is to employ an observer pattern and make references
                            observers of the attributes they must have to pass through in order to
                            get to an object.

                            Of course, another always-secure possibility is to recalculate a given
                            reference each time it is employed :-).

                            > As Self currently is this would be very likely since you add the slots
                            > graphically and they are shown in alphabetical order.

                            Yes, that's a problem. My VM also currently sorts members of each
                            object alphabetically, I mean internally, though it doesn't offer
                            multiple inheritance.

                            > But for some
                            > scripting language this might be an interesting option. In early
                            > versions of Self/R I did have a depth first search exactly as you
                            > suggest but around the time I changed the name to Neo Smalltalk I
                            > decided to get rid of parents entirely and make the programmers manually
                            > order the "facets" which make up an object.

                            So you create your objects by joining mixins, perhaps ?

                            Salud !

                            Baltasar

                            --
                            PBC -- J. Baltasar García Perez-Schofield
                            jbgarcia en uvigo de es http://webs.uvigo.es/jbgarcia/
                            Dep. Informática, Universidad de Vigo, España (Spain)
                          • rimerenu
                            Hello, all! As it is currently discussed I want to ask a question about the performance of Self VM. While I haven t done benchmarks, when I ve run the Self VM
                            Message 13 of 16 , Nov 11, 2005
                            • 0 Attachment
                              Hello, all!

                              As it is currently discussed I want to ask a question about
                              the performance of Self VM. While I haven't done benchmarks,
                              when I've run the Self VM (4.2.1) in Mac the user interface
                              seemed to appear rather slow. The question is does just
                              the user interface is slow or the Self VM is slow
                              (for general application programming, not just scripting)
                              despite the great efforts for optimization. Is current
                              Self VM represents the final point in optimizations
                              for a prototype based dynamic language or there is
                              still room for substantial performance improvements.

                              Regards,
                              Emir Uner



                              PS: I apologize if this mail comes twice because the first time
                              I tried it failed.
                            • Jecel Assumpcao Jr
                              J. Baltasar Garcia Perez-Schofield wrote on Mon, 07 Nov 2005 19:53:33 +0100 ... Exactly. ... Normally each object is associated with a map that represents
                              Message 14 of 16 , Nov 11, 2005
                              • 0 Attachment
                                J. Baltasar Garcia Perez-Schofield" wrote on Mon, 07 Nov 2005 19:53:33
                                +0100
                                > Mmmm ... note I wrote resend/unqualified messages: as far as I
                                > understood, "resend.copy" and "copy" would behave the same but for the
                                > lookup in "self" which would happend in the second case but not in the
                                > first one.

                                Exactly.

                                > I'm very interested. My own virtual machine assumes that parent
                                > attributes can be changed anytime (not currently, sadly).
                                >
                                > http://trevinca.ei.uvigo.es/~jgarcia/TO/zero/
                                >
                                > So maybe you could explain what exactly you thought as a solution.
                                > Although I am not working in that part of the VM, my first design to
                                > overcome this is to employ an observer pattern and make references
                                > observers of the attributes they must have to pass through in order to
                                > get to an object.
                                >
                                > Of course, another always-secure possibility is to recalculate a given
                                > reference each time it is employed :-).

                                Normally each object is associated with a "map" that represents its type
                                to the virtual machine (pointers to maps are used in PICs and other
                                places). My change was to allow a single object to be associated with
                                more than one map (up to five) and was based on observations about how
                                dynamic inheritance is used in practice: normally a parent data slots
                                holds one among a few objects. So you have

                                _AddSlots: (| obj = (| parent* <- emptyTraits.
                                elements <- list copyRemoveAll |)
                                |)

                                ...

                                obj parent: fullTraits.

                                ...

                                obj parent: obsoleteTraits.


                                In this case there would be created a total of three different maps for
                                obj and 'parent:' would not be a simple assignment slot but would have
                                code to switch the map whenever it is executed. Since separate native
                                code is generated for a given message for each different map the lookup
                                happens at compile time just as if 'parent' were a constant slot.

                                A far more complicated case is when an object does not have itself
                                dynamic inheritance but one (or more) of its ancestors does. If this is
                                common enough then my scheme can be extended to handle it but it is
                                probably better to fall back on the "loop up every time" solution for
                                this. There is nothing special about my five maps per object limit but
                                like the limits in the PICs sizes after a point the advantages over the
                                general solution are no longer worth it.

                                > So you create your objects by joining mixins, perhaps ?

                                Exactly. I call them "facets" since they are used a bit differently than
                                traditional mixins and reusing the name might cause some confusion.
                                These facets (sets of slots) are ordered so it is easy to see (literally
                                given the visual representation) which slot will match each message. If
                                Self were converted directly to such a scheme most objects would be huge
                                due to the globals but I don't have globals in the language, though the
                                programming environment has a catalog that does the same job (but at
                                edit time, not run time).

                                -- Jecel
                              • Jecel Assumpcao Jr
                                Emir Uner wrote on Fri, 11 Nov 2005 14:30:59 -0000 ... Running Self on a 277MHz Sun Ultra 5 machine feels more responsive than on a 1GHz eMac even though all
                                Message 15 of 16 , Nov 11, 2005
                                • 0 Attachment
                                  Emir Uner wrote on Fri, 11 Nov 2005 14:30:59 -0000

                                  > As it is currently discussed I want to ask a question about
                                  > the performance of Self VM. While I haven't done benchmarks,
                                  > when I've run the Self VM (4.2.1) in Mac the user interface
                                  > seemed to appear rather slow. The question is does just
                                  > the user interface is slow or the Self VM is slow
                                  > (for general application programming, not just scripting)
                                  > despite the great efforts for optimization.

                                  Running Self on a 277MHz Sun Ultra 5 machine feels more responsive than
                                  on a 1GHz eMac even though all other applications run far faster on this
                                  second machine. You can have an idea of this effect comparing Self and
                                  Squeak benchmarks in http://minnow.cc.gatech.edu/squeak/768

                                  While far better than the Linux port, I don't think the Mac version of
                                  Self gives people the proper impression of the potential performance.
                                  But you are right that it would be a good idea to run benchmarks to see
                                  if it is a GUI only problem or if there is a general difference in
                                  performance. I will do so tomorrow and add the results to the page I
                                  mentioned above.

                                  > Is current
                                  > Self VM represents the final point in optimizations
                                  > for a prototype based dynamic language or there is
                                  > still room for substantial performance improvements.

                                  If this is related to the implementation discussion on the Io list you
                                  should be aware that "prototype language" means rather different things
                                  in Io and Self. It would be best if we had two separate names for them
                                  but I don't think that will happen. That said, the technology created
                                  for Self can apply to other languages and it can also be improved on.
                                  That, however, would not be a trivial project and nobody seems to be
                                  investing in this direction currently.

                                  The best way to research this is to step back and try to see the general
                                  mechanisms of which the various Self tricks are particular examples of.
                                  Like where Self uses customization and code splitting you might want to
                                  consider them from a partial evaluation viewpoint. Once you do that you
                                  begin to see other places where partial evaluation could be applied. The
                                  first step would probably be to extend the bad of tricks but eventually
                                  you might discover a more general framework that replaces all that. See
                                  the change from type inference (Self 1 and 2) to type feedback (Self 3
                                  and 4) for an example of what I am talking about.

                                  > PS: I apologize if this mail comes twice because the first time
                                  > I tried it failed.

                                  The first time you sent to self-interest-owner and only the list
                                  moderator (me) got it. Note to people sending their first messages to
                                  the list - every new member is initially moderated even though the list
                                  in general isn't. When I see your first email and I aprove it (which
                                  might take a while) I also change your settings so your following emails
                                  won't have any delays. This allows me to filter out the spam, either
                                  well intentioned (announcing Java events, for example) or not.

                                  -- Jecel
                                • J. Baltasar Garcia Perez-Schofield
                                  Hi. Jecel ... Interesting. Thank you for you answer. ... I see. But are these facets packed inside the object, or do you have slots pointing to them ? Salud
                                  Message 16 of 16 , Nov 14, 2005
                                  • 0 Attachment
                                    Hi. Jecel


                                    > Normally each object is associated with a "map" that represents its type
                                    > to the virtual machine (pointers to maps are used in PICs and other
                                    > places). My change was to allow a single object to be associated with
                                    > more than one map (up to five)

                                    Interesting.
                                    Thank you for you answer.

                                    > Exactly. I call them "facets" since they are used a bit differently than
                                    > traditional mixins and reusing the name might cause some confusion.
                                    > These facets (sets of slots) are ordered so it is easy to see (literally
                                    > given the visual representation) which slot will match each message. If
                                    > Self were converted directly to such a scheme most objects would be huge
                                    > due to the globals but I don't have globals in the language, though the
                                    > programming environment has a catalog that does the same job (but at
                                    > edit time, not run time).

                                    I see.
                                    But are these facets "packed" inside the object, or do you have slots
                                    pointing to them ?

                                    Salud !

                                    --
                                    PBC -- J. Baltasar García Perez-Schofield
                                    jbgarcia en uvigo de es http://webs.uvigo.es/jbgarcia/
                                    Dep. Informática, Universidad de Vigo, España (Spain)
                                  Your message has been successfully submitted and would be delivered to recipients shortly.