Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #22775

Re: The current object

Show all headers | View raw

Andrew Haley wrote:
> Well, yes, but you don't need to do pointless grunt-work: the whole
> point of encapsulation (and, therefore, of object-oriented
> programming) is to allow the programmer better and more abstract ways
> to think about programming.

Well, abstraction/encapsulation is one of four or five characteristics of 
OOP.  If you do OOP without encapsulation, it still has dynamic dispatch, 
subtype polymorphism and inheritance (and open recursion through self).  
That alone looks useful.

>> Yes.  Forth's design philosophy is about understanding the whole
>> program.  Encapsulation and isolation is for development where the
>> philosophy is that you should *not* understand the program.  This is
>> the road to bloated crap.
> 
> Not necessarily.  The point is surely to right-size the tools to the
> problem.

The philosophy that you should not understand the rest of the program is the 
road to bloated crap.  This is completely orthogonal to right-sizing the 
tool.

>> Ok, then there's at least something missing.  You have to update r1
>> at some point.
> 
> No, you just jump past any more checking.

Well, r1 contains the class you think it might be, but the first check fails 
if this is not the case.

>> How many of these tests do you need for a polymorphic dispatch?
>> Remember: *One* test is enough to make this slower than the vtable
>> call.
> 
> Well, that's your claim, but it depends on the hardware.  If vtables
> really are faster, we can do that; we can also do a couple of compare
> and branches.  So it'll be
> 
>    cmp r2, #x
>    beq ...
>    cmp r2, #y
>    beq ...
> 
> Of course, this is going to be slow if there are too many classes.

Indeed.  But if I'm right, on a Core i7, it is alreadly slower if there is 
one class, any additional class makes it worse.  And that has been sort-of 
true for quite some time in the x86 world, the branch target buffer is there 
for more than a decade.

>> I've seen arguments about vtable dispatching where people argue that
>> if your method is defined in a super class, you have to look it up
>> in the superclass vtable.  That's what I consider incompetence.  Of
>> course, you "finalize" your vtables so that they already contain the
>> superclass methods where necessary.
> 
> Sure, if you have a simple single inheritance dispatch you can do that.

You can always do that.  If it is a complex multiple inheritance dispatch, 
and you have dense vtables (as opposed to Anton's suggestion to have sparse 
vtables) you need the additional indirection with the selector_id -> 
vtable_offset map.

As long as there is a 1:1 selector->method relation (and that's an obvious 
truth), you can create a single vtable which does all the lookup you need.  
The additional indirection is supposed to improve memory usage, because it 
is supposed that classes cluster in sets which share the same methods (and 
if there are a few deviations, the compression algorithm could create some 
sparse elements in a mostly dense vtable to avoid creating too many offset 
maps).

A dynamic interactive OOP language will need some effort to fill in the 
vtables when you define/replace methods in already inherited superclasses, 
but then, that's a one-time per definition effort.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: The current object Bernd Paysan <bernd.paysan@gmx.de> - 2013-05-15 16:46 +0200
  Re: The current object Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-05-15 13:11 -0500
    Re: The current object Bernd Paysan <bernd.paysan@gmx.de> - 2013-05-15 23:23 +0200
      Re: The current object Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-05-16 02:24 -0500
        Re: The current object anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-05-16 13:55 +0000
        Re: The current object Bernd Paysan <bernd.paysan@gmx.de> - 2013-05-16 17:45 +0200
          Re: The current object Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-05-18 05:13 -0500
            Re: The current object Doug Hoffman <glidedog@gmail.com> - 2013-05-18 06:43 -0400
            Re: The current object Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-05-18 10:03 -0500
              Re: The current object Doug Hoffman <glidedog@gmail.com> - 2013-05-18 11:30 -0400
              Re: The current object Bernd Paysan <bernd.paysan@gmx.de> - 2013-05-19 01:20 +0200
                Re: The current object Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-05-19 12:33 -0500
            Re: The current object Bernd Paysan <bernd.paysan@gmx.de> - 2013-05-19 01:07 +0200
              Re: The current object Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-05-19 03:58 -0500
    OO dispatch (was: The current object) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-05-16 14:07 +0000
      Re: OO dispatch Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-05-18 05:28 -0500
        Re: OO dispatch anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-05-20 11:28 +0000
          Re: OO dispatch Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-05-20 09:00 -0500
            Re: OO dispatch Bernd Paysan <bernd.paysan@gmx.de> - 2013-05-21 01:37 +0200
              Re: OO dispatch Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-05-21 03:21 -0500
            Re: OO dispatch anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-05-21 12:24 +0000
              Re: OO dispatch Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-05-21 10:18 -0500
                Re: OO dispatch anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-05-21 16:03 +0000
                Re: OO dispatch Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-05-21 12:55 -0500
                Re: OO dispatch Bernd Paysan <bernd.paysan@gmx.de> - 2013-05-29 00:00 +0200
                Re: OO dispatch Mark Wills <markrobertwills@yahoo.co.uk> - 2013-05-28 15:49 -0700

csiph-web