On 26/09/2021 09:54, Dmitry A. Kazakov wrote:

....

> Historically Ada used the term subtype for a very narrow set of
> subtyping. So, to clarify one would say "Ada subtype", or "Liskov
> subtype" etc. Same with C++ classes, which are just types. C++ class
> reads "dynamically polymorphic type."
>

....

>
> OOP did not do that, in OOPL the terminology is as unsettled as anywhere
> else.

....

> But, one can agree on different terms, just define them, then it is OK.
> If you want to use "class" for "type" like in C++, that is fine, just
> give another word for class. Do not say they do not exist because you
> used the name...

....

>
> I have no issue with terms, but with broken semantics.
>

That is quite a post from this ng's biggest user of terms as if they
have one true meaning.

--
James Harris

On 22/10/2021 17:08, Dmitry A. Kazakov wrote:
> On 2021-10-22 17:45, James Harris wrote:
>> On 10/09/2021 08:08, Dmitry A. Kazakov wrote:
>>> On 2021-09-09 21:39, James Harris wrote:
>>>> On 03/09/2021 18:27, Dmitry A. Kazakov wrote:
>>>>> On 2021-09-03 18:43, James Harris wrote:
>>
>> ...
>>
>>>>>> Your example was good in showing multiple dispatch but I'm not so
>>>>>> sure it's a good solution in this case, let alone the only way!
>>>>>
>>>>> Of course it is. Write a program that renders a list of shapes in a
>>>>> widget in a way that you would not need to modify each time another
>>>>> developers team creates a new shape or supports another surface.
>>>>
>>>> Sure. I would have surfaces support different interfaces: pixmap,
>>>> vector and whatever else was needed, and have a basic set of
>>>> component shapes that surfaces could draw on themselves: lines,
>>>> triangles, rectangles, ellipses, etc, and bit blit. Then widgets
>>>> could then use those primitives to do all required drawing of basic
>>>> and complex shapes.
>>>
>>> Who calls these? Your rendering program?
>>
>> Shapes in the object model would render themselves on a given surface
>> by invoking the primitives which are provided by the surface. IOW each
>> surface would know how to draw basic shapes on itself and those
>> primitives could be invoked by the units in the object model.
>>
>>    ObjectModel --> Surface
>>
>> The ObjectModel would have components of arbitrary complexity. The
>> surface would provide /basic/ shapes only. (And all types of surface
>> would support the same interface, i.e. provide the same operations.)
>
> [...]
>
>>> You confuse implementation with means of. Rendering primitives are
>>> means to implement the procedure Draw you would call from your
>>> program for each element from the list shapes. The classic OO way:
>>>
>>>     for Shape in Shapes_List loop
>>>        Shape.Draw (Widget.Get_Redenring Context);
>>>           -- Dispatches to the Shape's Draw
>>>     end loop;
>>>
>>> Your way?
>>
>> The same except that the way Shape.Draw would draw itself would be by
>> calling primitives in the target surface.
>>
>> I know graphics contexts are common but I am not sure they are
>> distinct from a surface. Assuming they are comparable then your code
>> would become
>>
>>    Surface s
>>    ....
>>    for Shape in Shapes_List loop
>>      Shape.Draw(s)
>>    end loop
>>
>> Then the shape's Draw method would invoke one or more primitives of s.
>
> Good, you copied my example. So you do not deny that Draw dynamically
> dispatches on the actual type of Shape. q.e.d.

Certainly. I didn't think that point was in dispute.

As I understood it we were debating whether it was a good or a bad idea
for this application to have multiple dispatch on Shape and Surface
(with you saying it was the only way?!).

>
> ------------------------------------
> This example is called "double" or "cascading" dispatch, as opposed to
> full multiple dispatch. Instead of dispatching on both Shape and
> Surface, Draw dispatches only on Shape. Inside the implementation of
> Shape, the primitive rendering operations dispatch on Surface. E.g. an
> implementation of Draw might look like (note, the second argument is
> class-wide):
>
>    procedure Draw (X : Ellipse; S : in Surface'Class) is
>    begin
>       S.Push;
>       S.Move_Coordinates (X.Center_X, X.Center_Y);
>       S.Rotate_Coordinates (X.Angle);
>       S.Draw_Ellipse (X.Width, Y.Height);
>       S.Pop;
>    end Draw;
>
> So double dispatch is Shape first, Surface second. The obvious
> disadvantage is performance loss as you have to dispatch multiple times.
>

And as we've discussed, the dynamic dispatch that OO proponents are
normally so keen on is much slooooooower than a function call. They seem
to accept its poor performance without complaint when they want to. ;-)

--
James Harris

On 2021-10-23 10:46, James Harris wrote:
> On 22/10/2021 17:08, Dmitry A. Kazakov wrote:
>> On 2021-10-22 17:45, James Harris wrote:

>>> I know graphics contexts are common but I am not sure they are
>>> distinct from a surface. Assuming they are comparable then your code
>>> would become
>>>
>>>    Surface s
>>>    ....
>>>    for Shape in Shapes_List loop
>>>      Shape.Draw(s)
>>>    end loop
>>>
>>> Then the shape's Draw method would invoke one or more primitives of s.
>>
>> Good, you copied my example. So you do not deny that Draw dynamically
>> dispatches on the actual type of Shape. q.e.d.
>
> Certainly. I didn't think that point was in dispute.

No? How then to interpret this sentence a few lines below:

[...]

> And as we've discussed, the dynamic dispatch that OO proponents are
> normally so keen on is much slooooooower than a function call. They seem
> to accept its poor performance without complaint when they want to. ;-)

1. Where is your solution to drawing a list of shapes without dispatch?
So far you proposed exactly what OO proponents do.

2. It is double dispatch work-around that is slow. Multiple dispatch
dispatches just once.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 23/10/2021 09:59, Dmitry A. Kazakov wrote:
> On 2021-10-23 10:46, James Harris wrote:
>> On 22/10/2021 17:08, Dmitry A. Kazakov wrote:
>>> On 2021-10-22 17:45, James Harris wrote:
>
>>>> I know graphics contexts are common but I am not sure they are
>>>> distinct from a surface. Assuming they are comparable then your code
>>>> would become
>>>>
>>>>    Surface s
>>>>    ....
>>>>    for Shape in Shapes_List loop
>>>>      Shape.Draw(s)
>>>>    end loop
>>>>
>>>> Then the shape's Draw method would invoke one or more primitives of s.
>>>
>>> Good, you copied my example. So you do not deny that Draw dynamically
>>> dispatches on the actual type of Shape. q.e.d.
>>
>> Certainly. I didn't think that point was in dispute.
>
> No? How then to interpret this sentence a few lines below:

Two related topics in one post. Happens all the time.

>
> [...]
>
>> And as we've discussed, the dynamic dispatch that OO proponents are
>> normally so keen on is much slooooooower than a function call. They
>> seem to accept its poor performance without complaint when they want
>> to. ;-)
>
> 1. Where is your solution to drawing a list of shapes without dispatch?
> So far you proposed exactly what OO proponents do.
>
> 2. It is double dispatch work-around that is slow. Multiple dispatch
> dispatches just once.
>

Performance is a big subject but why not. First, let's review what has
been proposed here by OO proponents (AIUI):

1. Store a tag with the object.

2. Use the tag and the name of the intended callee to find the right
callee for the types of one or more parameters. The right callee would
be found by, incredibly, sequential or binary search, possibly fronted
with a hash-table lookup.

3. Invoke the appropriate callee.

Astonishingly, with dynamic dispatch step 2 could be required on each call.

To look at performance one needs to separate what comes out of the
compiler with what goes in to it. What comes out needs to be optimised,
naturally, but what goes in needs to be optimis**able**. Making a
language optimisable requires good design and, in particular, allowing a
programmer to express info that the programmer has but which a naive
language would not allow him to include.

So what should come out of the compiler? That's the same as if one were
writing in assembly.

In this case, if there are very few surfaces I might implement (in
assembly or in the compiler's output) what you might call /static/
dispatch by duplicating the assembly code for shapes (one copy for each
surface) and call directly. To invoke the circle routine for surface A:

call surface_A_circle

If that were not feasible or were not suitable here because the number
of surfaces were large or unknown I might implement single dispatch by
means of a jump table. If EBX points at the jump table and CIRCLE is the
offset into that table for where the surface's circle routine begins then

mov eax, [ebx + CIRCLE]
call eax

would invoke the callee. That's pretty fast.

No sequential search needed. No binary search needed. No hash lookup
needed. No vast array of pointers needed.

--
James Harris

On 2021-10-23 12:02, James Harris wrote:
> On 23/10/2021 09:59, Dmitry A. Kazakov wrote:
>> On 2021-10-23 10:46, James Harris wrote:
>>> On 22/10/2021 17:08, Dmitry A. Kazakov wrote:
>>>> On 2021-10-22 17:45, James Harris wrote:
>>
>>>>> I know graphics contexts are common but I am not sure they are
>>>>> distinct from a surface. Assuming they are comparable then your
>>>>> code would become
>>>>>
>>>>>    Surface s
>>>>>    ....
>>>>>    for Shape in Shapes_List loop
>>>>>      Shape.Draw(s)
>>>>>    end loop
>>>>>
>>>>> Then the shape's Draw method would invoke one or more primitives of s.
>>>>
>>>> Good, you copied my example. So you do not deny that Draw
>>>> dynamically dispatches on the actual type of Shape. q.e.d.
>>>
>>> Certainly. I didn't think that point was in dispute.
>>
>> No? How then to interpret this sentence a few lines below:
>
> Two related topics in one post. Happens all the time.
>
>>
>> [...]
>>
>>> And as we've discussed, the dynamic dispatch that OO proponents are
>>> normally so keen on is much slooooooower than a function call. They
>>> seem to accept its poor performance without complaint when they want
>>> to. ;-)
>>
>> 1. Where is your solution to drawing a list of shapes without
>> dispatch? So far you proposed exactly what OO proponents do.
>>
>> 2. It is double dispatch work-around that is slow. Multiple dispatch
>> dispatches just once.
>>
>
> Performance is a big subject but why not. First, let's review what has
> been proposed here by OO proponents (AIUI):
>
> 1. Store a tag with the object.

Only class-wide objects need tags. You refer to a specific
implementation, which is good for objects passed by reference and
unusable for objects passed by value.

> 2. Use the tag and the name of the intended callee to find the right
> callee for the types of one or more parameters. The right callee would
> be found by, incredibly, sequential or binary search, possibly fronted
> with a hash-table lookup.

Wrong. If restricted to single dispatch the tag could be implemented as
a pointer to the type-specific dispatching vector. The vector keeps a
pointer for each method:

vptr
..----------------.
| Draw |
+----------------+
| Rotate |
+----------------+
| Scale |
+----------------+
| ... |

Dispatch over such object would be just

call *vptr [offset]

where offset is a statically known dense index. E.g. 0 for Draw. No
search, no look-ups.

The drawbacks of this design are restriction to the single dispatch and
necessity to allocate new table for each specific type.

[...]

> In this case, if there are very few surfaces I might implement (in
> assembly or in the compiler's output) what you might call /static/
> dispatch by duplicating the assembly code for shapes (one copy for each
> surface) and call directly. To invoke the circle routine for surface A:
>
>   call surface_A_circle

The case is a list of any shapes to draw. How to invoke the right
routine? How to write a cycle over the list calling that routines?

Stop evading, provide a code/pseudo-code of drawing shapes from the list
without knowing specific types and their specific functions like
surface_A_circle.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 23/10/2021 12:18, Dmitry A. Kazakov wrote:
> On 2021-10-23 12:02, James Harris wrote:
>> On 23/10/2021 09:59, Dmitry A. Kazakov wrote:
>>> On 2021-10-23 10:46, James Harris wrote:
>>>> On 22/10/2021 17:08, Dmitry A. Kazakov wrote:
>>>>> On 2021-10-22 17:45, James Harris wrote:

....

>>>> And as we've discussed, the dynamic dispatch that OO proponents are
>>>> normally so keen on is much slooooooower than a function call. They
>>>> seem to accept its poor performance without complaint when they want
>>>> to. ;-)
>>>
>>> 1. Where is your solution to drawing a list of shapes without
>>> dispatch? So far you proposed exactly what OO proponents do.
>>>
>>> 2. It is double dispatch work-around that is slow. Multiple dispatch
>>> dispatches just once.
>>>
>>
>> Performance is a big subject but why not. First, let's review what has
>> been proposed here by OO proponents (AIUI):
>>
>> 1. Store a tag with the object.
>
> Only class-wide objects need tags.

I don't know what you are talking about. Wikipedia's closest is

https://en.wikipedia.org/wiki/Classwide_Peer_Tutoring

If it's important it might be best for you to put it in words rather
than relying on jargon. If you are using Ada jargon please don't; not
everyone else is familiar with it.

> You refer to a specific
> implementation, which is good for objects passed by reference and
> unusable for objects passed by value.

Again, I don't know what you are talking about. This has nothing to do
with whether an argument is passed by value or by reference - both of
which are implementation issues.

>
>> 2. Use the tag and the name of the intended callee to find the right
>> callee for the types of one or more parameters. The right callee would
>> be found by, incredibly, sequential or binary search, possibly fronted
>> with a hash-table lookup.
>
> Wrong. If restricted to single dispatch the tag could be implemented as
> a pointer to the type-specific dispatching vector. The vector keeps a
> pointer for each method:
>
> vptr
> .----------------.
> |  Draw          |
> +----------------+
> |  Rotate        |
> +----------------+
> |  Scale         |
> +----------------+
> |   ...          |
>

They look like methods of Shape. To be clear, I was talking about
calling methods of Surface from within a Shape method as they were more
performance critical and you asked about performance.

For example, you gave this code:

procedure Draw (X : Ellipse; S : in Surface'Class) is
begin
S.Push;
S.Move_Coordinates (X.Center_X, X.Center_Y);
S.Rotate_Coordinates (X.Angle);
S.Draw_Ellipse (X.Width, Y.Height);
S.Pop;
end Draw;

That has /one/ Shape method calling /many/ Surface methods so the
performance of calls to Surface methods would dominate. I was replying
to that challenge.

>
> Dispatch over such object would be just
>
>    call *vptr [offset]
>
> where offset is a statically known dense index. E.g. 0 for Draw. No
> search, no look-ups.

Yes.

>
> The drawbacks of this design are restriction to the single dispatch and
> necessity to allocate new table for each specific type.

It's a characteristic. It's not necessarily a drawback. For example:

* The double dispatch that you objected to on performance grounds would,
in fact, be fast, likely much faster than a complex multiple-dispatch
lookup.

* It is guaranteed not to have any problems scaling. Each type (class)
would need only as many pointers as the number of functions (methods) as
are in the source code.

>
> [...]
>
>> In this case, if there are very few surfaces I might implement (in
>> assembly or in the compiler's output) what you might call /static/
>> dispatch by duplicating the assembly code for shapes (one copy for
>> each surface) and call directly. To invoke the circle routine for
>> surface A:
>>
>>    call surface_A_circle
>
> The case is a list of any shapes to draw. How to invoke the right
> routine? How to write a cycle over the list calling that routines?

I think you may have misread it. The above was calling a /Surface/
function from within a Shape function. Hence the target routine's
name!!! And as I stated, the static-dispatch code was for the case where
Shape code had been duplicated, one copy for each Surface type, so as to
achieve maximum performance.

I provided another snippet (which you dropped) for how to execute
dynamic dispatch based on a jump table (or similar) for use where the
Shape code was not duplicated.

But if it's Shapes you are interested in and wanted to invoke the Draw
function on a Shape of unknown type why not use that method:

mov eax, [ebx + DRAW]
call eax

? What's wrong with that?

>
> Stop evading,

Phew! I provide explanation and code down to assembler level and you
call it evading? Riiight! I think you need to work on your tact - and
your grip on reality!!! :-(

> provide a code/pseudo-code of drawing shapes from the list
> without knowing specific types and their specific functions like
> surface_A_circle.
>

OK. HLL:

type Circle
function Draw(Surface S)
S.DrawCircle(X, Y, R)
end function
end type

Shape s
Surface surf = CurrentSurface(context)
s = shape[i]
s.Draw(surf)

where s.Draw would be invoked by

mov eax, [ebx + DRAW]
call eax

With that example, the Circle's Draw function could not use static
dispatch and would need to use single dynamic dispatch (trying my best
to use your preferred terms) to invoke the Surface's DrawCircle function.

--
James Harris

On 2021-10-23 19:15, James Harris wrote:
> On 23/10/2021 12:18, Dmitry A. Kazakov wrote:
>> On 2021-10-23 12:02, James Harris wrote:
>>> On 23/10/2021 09:59, Dmitry A. Kazakov wrote:
>>>> On 2021-10-23 10:46, James Harris wrote:
>>>>> On 22/10/2021 17:08, Dmitry A. Kazakov wrote:
>>>>>> On 2021-10-22 17:45, James Harris wrote:
>
> ...
>
>>>>> And as we've discussed, the dynamic dispatch that OO proponents are
>>>>> normally so keen on is much slooooooower than a function call. They
>>>>> seem to accept its poor performance without complaint when they
>>>>> want to. ;-)
>>>>
>>>> 1. Where is your solution to drawing a list of shapes without
>>>> dispatch? So far you proposed exactly what OO proponents do.
>>>>
>>>> 2. It is double dispatch work-around that is slow. Multiple dispatch
>>>> dispatches just once.
>>>>
>>>
>>> Performance is a big subject but why not. First, let's review what
>>> has been proposed here by OO proponents (AIUI):
>>>
>>> 1. Store a tag with the object.
>>
>> Only class-wide objects need tags.
>
> I don't know what you are talking about.

Object you can dispatch on is called class-wide.

You cannot dispatch on any argument of any C++ function except on the
first one. So, you need no tags for any them.

>> You refer to a specific implementation, which is good for objects
>> passed by reference and unusable for objects passed by value.
>
> Again, I don't know what you are talking about. This has nothing to do
> with whether an argument is passed by value or by reference - both of
> which are implementation issues.

It has everything to do with that if you thought about what is dispatch
and which kind of objects are usually passed by value.

>>> 2. Use the tag and the name of the intended callee to find the right
>>> callee for the types of one or more parameters. The right callee
>>> would be found by, incredibly, sequential or binary search, possibly
>>> fronted with a hash-table lookup.
>>
>> Wrong. If restricted to single dispatch the tag could be implemented
>> as a pointer to the type-specific dispatching vector. The vector keeps
>> a pointer for each method:
>>
>> vptr
>> .----------------.
>> |  Draw          |
>> +----------------+
>> |  Rotate        |
>> +----------------+
>> |  Scale         |
>> +----------------+
>> |   ...          |
>>
>
> They look like methods of Shape. To be clear, I was talking about
> calling methods of Surface from within a Shape method as they were more
> performance critical and you asked about performance.

And what makes you think that vptr would work for Shapes but not for
Surfaces?

>> The drawbacks of this design are restriction to the single dispatch
>> and necessity to allocate new table for each specific type.
>
> It's a characteristic. It's not necessarily a drawback. For example:
>
> * The double dispatch that you objected to on performance grounds would,
> in fact, be fast, likely much faster than a complex multiple-dispatch
> lookup.

No, because you must re-dispatch inside Draw. Since Draw is class-wide
on the surface argument its implementation must work for all possible
instances of surface. That is a heavy burden as you must provide a
unified fat interface for all possible surfaces.

> * It is guaranteed not to have any problems scaling. Each type (class)
> would need only as many pointers as the number of functions (methods) as
> are in the source code.

It is guaranteed to have issues being a generic implementation for all
surfaces. Such things never scale well. Decomposition of multiple
dispatch into a cascaded dispatch is not always possible.

>> Stop evading,
>
> Phew! I provide explanation and code down to assembler level and you
> call it evading? Riiight! I think you need to work on your tact - and
> your grip on reality!!! :-(

I do not care about assembler. You claimed you do not need dispatch, I
want to see the code that does not dispatch, yet works.

>> provide a code/pseudo-code of drawing shapes from the list without
>> knowing specific types and their specific functions like
>> surface_A_circle.
>>
>
> OK. HLL:
>
>   type Circle
>     function Draw(Surface S)
>        S.DrawCircle(X, Y, R)
>     end function
>   end type
>
>   Shape s
>   Surface surf = CurrentSurface(context)
>   s = shape[i]
>   s.Draw(surf)

Since s has the type Shape, I presume the declaration

Shape s

means that? So s.Draw must call Draw of the type Shape instead of Draw
of the type of the original object, e.g. Circle, Ellipse, Rectangle etc?
You killed that object when you assigned and converted/upcasted it to
its parent type Shape. How is that even possible to convert Circle to
Shape, there is no any hints that Circle is somehow related to it, or
that Draw of Circle overrides Draw of Shape?

Why

for i in ...
shape[i].Draw(CurrentSurface(context))

is not OK and how it would not dispatch?

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 23/10/2021 20:53, Dmitry A. Kazakov wrote:
> On 2021-10-23 19:15, James Harris wrote:
>> On 23/10/2021 12:18, Dmitry A. Kazakov wrote:
>>> On 2021-10-23 12:02, James Harris wrote:
>>>> On 23/10/2021 09:59, Dmitry A. Kazakov wrote:
>>>>> On 2021-10-23 10:46, James Harris wrote:
>>>>>> On 22/10/2021 17:08, Dmitry A. Kazakov wrote:
>>>>>>> On 2021-10-22 17:45, James Harris wrote:
>>
>> ...
>>
>>>>>> And as we've discussed, the dynamic dispatch that OO proponents
>>>>>> are normally so keen on is much slooooooower than a function call.
>>>>>> They seem to accept its poor performance without complaint when
>>>>>> they want to. ;-)
>>>>>
>>>>> 1. Where is your solution to drawing a list of shapes without
>>>>> dispatch? So far you proposed exactly what OO proponents do.
>>>>>
>>>>> 2. It is double dispatch work-around that is slow. Multiple
>>>>> dispatch dispatches just once.
>>>>>
>>>>
>>>> Performance is a big subject but why not. First, let's review what
>>>> has been proposed here by OO proponents (AIUI):
>>>>
>>>> 1. Store a tag with the object.
>>>
>>> Only class-wide objects need tags.
>>
>> I don't know what you are talking about.
>
> Object you can dispatch on is called class-wide.
>
> You cannot dispatch on any argument of any C++ function except on the
> first one. So, you need no tags for any them.

You mean /dynamic/ dispatch? You are saying the tag is needed where the
correct function cannot be known at compile time. Correct?

>
>>> You refer to a specific implementation, which is good for objects
>>> passed by reference and unusable for objects passed by value.
>>
>> Again, I don't know what you are talking about. This has nothing to do
>> with whether an argument is passed by value or by reference - both of
>> which are implementation issues.
>
> It has everything to do with that if you thought about what is dispatch
> and which kind of objects are usually passed by value.

How "usually"? AISI, if there's overloading then selection of which
procedure to call should be based purely on the /types/ of one or more
parameters. How they are /usually/ passed has to be a matter of the
greatest irrelevance! :-(

>
>>>> 2. Use the tag and the name of the intended callee to find the right
>>>> callee for the types of one or more parameters. The right callee
>>>> would be found by, incredibly, sequential or binary search, possibly
>>>> fronted with a hash-table lookup.
>>>
>>> Wrong. If restricted to single dispatch the tag could be implemented
>>> as a pointer to the type-specific dispatching vector. The vector
>>> keeps a pointer for each method:
>>>
>>> vptr
>>> .----------------.
>>> |  Draw          |
>>> +----------------+
>>> |  Rotate        |
>>> +----------------+
>>> |  Scale         |
>>> +----------------+
>>> |   ...          |
>>>
>>
>> They look like methods of Shape. To be clear, I was talking about
>> calling methods of Surface from within a Shape method as they were
>> more performance critical and you asked about performance.
>
> And what makes you think that vptr would work for Shapes but not for
> Surfaces?

Whatever vptr is I didn't say it had limited application but from the
routine names you used you seemed to be thinking of something other than
what I had written about.

>
>>> The drawbacks of this design are restriction to the single dispatch
>>> and necessity to allocate new table for each specific type.
>>
>> It's a characteristic. It's not necessarily a drawback. For example:
>>
>> * The double dispatch that you objected to on performance grounds
>> would, in fact, be fast, likely much faster than a complex
>> multiple-dispatch lookup.
>
> No, because you must re-dispatch inside Draw. Since Draw is class-wide
> on the surface argument its implementation must work for all possible
> instances of surface. That is a heavy burden as you must provide a
> unified fat interface for all possible surfaces.

I don't think that's right. For example, imagine that there are many
surfaces all with the same interface. The addresses of the functions
therein would be present in a jump table or vector. If a certain shape
wanted to draw part or all of itself on the surface it would only have
to invoke the correct routine or routines. And for each call it would
pick the routine which was the specified offset into the jump table or
vector.

For example, say every surface had a DrawRectangle() function and that
the address of all such functions was 40 bytes from the start of the
relevant vector (one vector per surface). The call to the routine would
be of the form

mov eax, [ebx + 40]
call eax

In case it's not clear, that loads into EAX the word which is 40 bytes
after where EBX points, then it calls the routine at the address which
is in EAX.

That's not slow. That's fast. And it wouldn't matter how many surfaces
there were. All surfaces would have their routines addressed by a
similar vector. And all DrawRectangle routines would have their
addresses 40 bytes from the start of the relevant vector.

>
>> * It is guaranteed not to have any problems scaling. Each type (class)
>> would need only as many pointers as the number of functions (methods)
>> as are in the source code.
>
> It is guaranteed to have issues being a generic implementation for all
> surfaces. Such things never scale well. Decomposition of multiple
> dispatch into a cascaded dispatch is not always possible.

There may indeed be cases where what I am suggesting would not work well
but AFIACS this is not one of them!

>
>>> Stop evading,
>>
>> Phew! I provide explanation and code down to assembler level and you
>> call it evading? Riiight! I think you need to work on your tact - and
>> your grip on reality!!! :-(
>
> I do not care about assembler. You claimed you do not need dispatch, I
> want to see the code that does not dispatch, yet works.

You should care about assembly. Everything we write gets turned into
assembly eventually and it's a good way to show specifics of how
something might be implemented. I think the asm I have been posting is
clear enough even for someone who doesn't know assembly but if not let
me know.

>
>>> provide a code/pseudo-code of drawing shapes from the list without
>>> knowing specific types and their specific functions like
>>> surface_A_circle.
>>>
>>
>> OK. HLL:
>>
>>    type Circle
>>      function Draw(Surface S)
>>         S.DrawCircle(X, Y, R)
>>      end function
>>    end type
>>
>>    Shape s
>>    Surface surf = CurrentSurface(context)
>>    s = shape[i]
>>    s.Draw(surf)
>
> Since s has the type Shape, I presume the declaration
>
>    Shape s
>
> means that?

Yes.

> So s.Draw must call Draw of the type Shape instead of Draw
> of the type of the original object, e.g. Circle, Ellipse, Rectangle etc?

No, the intention was that it call Draw of the specific shape returned by

shape[i]

That could be a Circle, a Rectangle etc.

> You killed that object when you assigned and converted/upcasted it to
> its parent type Shape. How is that even possible to convert Circle to
> Shape, there is no any hints that Circle is somehow related to it, or
> that Draw of Circle overrides Draw of Shape?

Maybe I've missed something but what I have in mind is that

s = shape[i]

would set s to whatever Shape is in the array at index i. All shapes
would have a Draw function at the same offset in a vector. The vector
would be found by the compiled code consulting the tag which is part of
the shape structure. (I'd have the tag /point at/ the vector.)

>
> Why
>
>    for i in ...
>       shape[i].Draw(CurrentSurface(context))
>
> is not OK and how it would not dispatch?
>

That looks OK except that I'd store the Surface rather than looking it
up each time.

Don't forget there are two or more function-selection operations. One
would select the Draw function for the particular Shape involved. Then
that function would call one or more /Surface/ functions. In simple
terms, all such calls would use the

On 2021-10-25 16:04, James Harris wrote:
> On 23/10/2021 20:53, Dmitry A. Kazakov wrote:
>> On 2021-10-23 19:15, James Harris wrote:
>>> On 23/10/2021 12:18, Dmitry A. Kazakov wrote:
>>>> On 2021-10-23 12:02, James Harris wrote:
>>>>> On 23/10/2021 09:59, Dmitry A. Kazakov wrote:
>>>>>> On 2021-10-23 10:46, James Harris wrote:
>>>>>>> On 22/10/2021 17:08, Dmitry A. Kazakov wrote:
>>>>>>>> On 2021-10-22 17:45, James Harris wrote:
>>>
>>> ...
>>>
>>>>>>> And as we've discussed, the dynamic dispatch that OO proponents
>>>>>>> are normally so keen on is much slooooooower than a function
>>>>>>> call. They seem to accept its poor performance without complaint
>>>>>>> when they want to. ;-)
>>>>>>
>>>>>> 1. Where is your solution to drawing a list of shapes without
>>>>>> dispatch? So far you proposed exactly what OO proponents do.
>>>>>>
>>>>>> 2. It is double dispatch work-around that is slow. Multiple
>>>>>> dispatch dispatches just once.
>>>>>>
>>>>>
>>>>> Performance is a big subject but why not. First, let's review what
>>>>> has been proposed here by OO proponents (AIUI):
>>>>>
>>>>> 1. Store a tag with the object.
>>>>
>>>> Only class-wide objects need tags.
>>>
>>> I don't know what you are talking about.
>>
>> Object you can dispatch on is called class-wide.
>>
>> You cannot dispatch on any argument of any C++ function except on the
>> first one. So, you need no tags for any them.
>
> You mean /dynamic/ dispatch? You are saying the tag is needed where the
> correct function cannot be known at compile time. Correct?

Yes.

>>>> You refer to a specific implementation, which is good for objects
>>>> passed by reference and unusable for objects passed by value.
>>>
>>> Again, I don't know what you are talking about. This has nothing to
>>> do with whether an argument is passed by value or by reference - both
>>> of which are implementation issues.
>>
>> It has everything to do with that if you thought about what is
>> dispatch and which kind of objects are usually passed by value.
>
> How "usually"?

Like *always* since FORTRAN-IV times.

> AISI, if there's overloading then selection of which
> procedure to call should be based purely on the /types/ of one or more
> parameters. How they are /usually/ passed has to be a matter of the
> greatest irrelevance! :-(

Why do you mention irrelevant things?

>>>>> 2. Use the tag and the name of the intended callee to find the
>>>>> right callee for the types of one or more parameters. The right
>>>>> callee would be found by, incredibly, sequential or binary search,
>>>>> possibly fronted with a hash-table lookup.
>>>>
>>>> Wrong. If restricted to single dispatch the tag could be implemented
>>>> as a pointer to the type-specific dispatching vector. The vector
>>>> keeps a pointer for each method:
>>>>
>>>> vptr
>>>> .----------------.
>>>> |  Draw          |
>>>> +----------------+
>>>> |  Rotate        |
>>>> +----------------+
>>>> |  Scale         |
>>>> +----------------+
>>>> |   ...          |
>>>>
>>>
>>> They look like methods of Shape. To be clear, I was talking about
>>> calling methods of Surface from within a Shape method as they were
>>> more performance critical and you asked about performance.
>>
>> And what makes you think that vptr would work for Shapes but not for
>> Surfaces?
>
> Whatever vptr is I didn't say it had limited application but from the
> routine names you used you seemed to be thinking of something other than
> what I had written about.

It is enough to debunk you false claim about inefficiency of dispatch
implementations. One thing at a time.

>>>> The drawbacks of this design are restriction to the single dispatch
>>>> and necessity to allocate new table for each specific type.
>>>
>>> It's a characteristic. It's not necessarily a drawback. For example:
>>>
>>> * The double dispatch that you objected to on performance grounds
>>> would, in fact, be fast, likely much faster than a complex
>>> multiple-dispatch lookup.
>>
>> No, because you must re-dispatch inside Draw. Since Draw is class-wide
>> on the surface argument its implementation must work for all possible
>> instances of surface. That is a heavy burden as you must provide a
>> unified fat interface for all possible surfaces.
>
> I don't think that's right.

It is not right or wrong, it is how it is.

> For example, imagine that there are many
> surfaces all with the same interface.

There is nothing to imagine, see the code, or write the code.

> There may indeed be cases where what I am suggesting would not work well
> but AFIACS this is not one of them!

You never presented anything different from double dispatch.

>>>> Stop evading,
>>>
>>> Phew! I provide explanation and code down to assembler level and you
>>> call it evading? Riiight! I think you need to work on your tact - and
>>> your grip on reality!!! :-(
>>
>> I do not care about assembler. You claimed you do not need dispatch, I
>> want to see the code that does not dispatch, yet works.
>
> You should care about assembly. Everything we write gets turned into
> assembly eventually and it's a good way to show specifics of how
> something might be implemented.

Everything is actually turned into heat dissipated by the CPU radiator,
and I do not care.

>>>> provide a code/pseudo-code of drawing shapes from the list without
>>>> knowing specific types and their specific functions like
>>>> surface_A_circle.
>>>>
>>>
>>> OK. HLL:
>>>
>>>    type Circle
>>>      function Draw(Surface S)
>>>         S.DrawCircle(X, Y, R)
>>>      end function
>>>    end type
>>>
>>>    Shape s
>>>    Surface surf = CurrentSurface(context)
>>>    s = shape[i]
>>>    s.Draw(surf)
>>
>> Since s has the type Shape, I presume the declaration
>>
>>     Shape s
>>
>> means that?
>
> Yes.
>
>> So s.Draw must call Draw of the type Shape instead of Draw of the type
>> of the original object, e.g. Circle, Ellipse, Rectangle etc?
>
> No, the intention was that it call Draw of the specific shape returned by
>
>   shape[i]

By reading minds?

> That could be a Circle, a Rectangle etc.

How? The type is Shape. Circle is a different type.

[...]

> Maybe I've missed something but what I have in mind is that
>
>   s = shape[i]

You missed types, as always. The type of s, should not have been Shape,
but "any instance of any type derived from Shape or Shape itself."

See, why such types and objects are called class-wide?

> would set s to whatever Shape is in the array at index i. All shapes
> would have a Draw function at the same offset in a vector. The vector
> would be found by the compiled code consulting the tag which is part of
> the shape structure. (I'd have the tag /point at/ the vector.)
>
>>
>> Why
>>
>>     for i in ...
>>        shape[i].Draw(CurrentSurface(context))
>>
>> is not OK and how it would not dispatch?
>>
>
> That looks OK except that I'd store the Surface rather than looking it
> up each time.

Store? Rendering context cannot be copied, not unless creating a
completely independent one.

In a decent language one can *rename* objects rename /= store.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 25/10/2021 15:34, Dmitry A. Kazakov wrote:
> On 2021-10-25 16:04, James Harris wrote:
>> On 23/10/2021 20:53, Dmitry A. Kazakov wrote:
>>> On 2021-10-23 19:15, James Harris wrote:
>>>> On 23/10/2021 12:18, Dmitry A. Kazakov wrote:

....

> It is enough to debunk you false claim about inefficiency of dispatch
> implementations. One thing at a time.

LOL! If that's your goal it helps explain some of your replies!!!

And it's a vain hope. You should realise you are wrong! :-)

....

>>>>> provide a code/pseudo-code of drawing shapes from the list without
>>>>> knowing specific types and their specific functions like
>>>>> surface_A_circle.
>>>>>
>>>>
>>>> OK. HLL:
>>>>
>>>>    type Circle
>>>>      function Draw(Surface S)
>>>>         S.DrawCircle(X, Y, R)
>>>>      end function
>>>>    end type
>>>>
>>>>    Shape s
>>>>    Surface surf = CurrentSurface(context)
>>>>    s = shape[i]
>>>>    s.Draw(surf)
>>>
>>> Since s has the type Shape, I presume the declaration
>>>
>>>     Shape s
>>>
>>> means that?
>>
>> Yes.
>>
>>> So s.Draw must call Draw of the type Shape instead of Draw of the
>>> type of the original object, e.g. Circle, Ellipse, Rectangle etc?
>>
>> No, the intention was that it call Draw of the specific shape returned by
>>
>>    shape[i]
>
> By reading minds?

Er, no, by using the object's tag to locate a vector of routine
addresses - as in the code I have posted multiple times. Asm is easier
and clearer but in an HLL such as C (and a C expert may correct the
following) if p is a pointer to the Shape object then

v = *p

would make v a pointer to the vector of function addresses. Then

a = v[DRAW]

would make a point to the Draw routine for whatever Shape the object is.
That line is the equivalent of

mov eax, [ebx + 40]

that I've posted before. Then

(*a)(....)

would call the routine.

>
>> That could be a Circle, a Rectangle etc.
>
> How? The type is Shape. Circle is a different type.

All Shapes have attributes in common. In the example, all Shapes have a
Draw function. Further, for all Shapes the address of that function is
40 bytes from the start of the table of function addresses. Hence the
code can reach the appropriate Draw method whichever shape is present.

I am talking about /how/ things can be done but if you think it's not
possible then perhaps you can explain how what I am proposing is
different from single dispatch Liskov substitution - something with
which I think you agree?

Note: "Substitutability is a principle in object-oriented programming
stating that, in a computer program, if S is a subtype of T, then
objects of type T may be replaced with objects of type S (i.e., an
object of type T may be substituted with any object of a subtype S)
without altering any of the desirable properties of the program
(correctness, task performed, etc.)."

https://en.wikipedia.org/wiki/Liskov_substitution_principle

I don't normally use the terminology but for the example I think the
nomenclature would be that Circle and Rectangle etc are 'subtypes' of
Shape. So 'an object of type Shape may be replaced with an object of
type Rectangle', no?

Or are you just trying to wind me up....? :-(

>
> [...]
>
>> Maybe I've missed something but what I have in mind is that
>>
>>    s = shape[i]
>
> You missed types, as always. The type of s, should not have been Shape,
> but "any instance of any type derived from Shape or Shape itself."

In the model I was putting forward an object which has been declared of
type Shape can be any shape. At the byte level all it means is that all
objects of type Shape support /the Shape interface/.

....

>>> Why
>>>
>>>     for i in ...
>>>        shape[i].Draw(CurrentSurface(context))
>>>
>>> is not OK and how it would not dispatch?
>>>
>>
>> That looks OK except that I'd store the Surface rather than looking it
>> up each time.
>
> Store? Rendering context cannot be copied, not unless creating a
> completely independent one.

My example included:

Surface surf = CurrentSurface(context)

then, later,

s.Draw(surf)

The variable 'surf' would be a reference and would, in general, take up
just one word.

--
James Harris

On 2021-10-25 17:33, James Harris wrote:
> On 25/10/2021 15:34, Dmitry A. Kazakov wrote:
>> On 2021-10-25 16:04, James Harris wrote:
>>> On 23/10/2021 20:53, Dmitry A. Kazakov wrote:
>>>> On 2021-10-23 19:15, James Harris wrote:
>>>>> On 23/10/2021 12:18, Dmitry A. Kazakov wrote:
>
> ...
>
>> It is enough to debunk you false claim about inefficiency of dispatch
>> implementations. One thing at a time.
>
> LOL! If that's your goal it helps explain some of your replies!!!
>
> And it's a vain hope. You should realise you are wrong! :-)

I presented an implementation of dispatch which complexity is adding
offset and doing call. Is that inefficient?

>>>>>> provide a code/pseudo-code of drawing shapes from the list without
>>>>>> knowing specific types and their specific functions like
>>>>>> surface_A_circle.
>>>>>>
>>>>>
>>>>> OK. HLL:
>>>>>
>>>>>    type Circle
>>>>>      function Draw(Surface S)
>>>>>         S.DrawCircle(X, Y, R)
>>>>>      end function
>>>>>    end type
>>>>>
>>>>>    Shape s
>>>>>    Surface surf = CurrentSurface(context)
>>>>>    s = shape[i]
>>>>>    s.Draw(surf)
>>>>
>>>> Since s has the type Shape, I presume the declaration
>>>>
>>>>     Shape s
>>>>
>>>> means that?
>>>
>>> Yes.
>>>
>>>> So s.Draw must call Draw of the type Shape instead of Draw of the
>>>> type of the original object, e.g. Circle, Ellipse, Rectangle etc?
>>>
>>> No, the intention was that it call Draw of the specific shape
>>> returned by
>>>
>>>    shape[i]
>>
>> By reading minds?
>
> Er, no, by using the object's tag to locate a vector of routine
> addresses - as in the code I have posted multiple times.

But you converted the type in assignment. s is Shape, it is not Circle.
Why on earth it should look after any tags? Oh, each call must always go
through the vptr? This is what C++ does. It is inefficient and
semantically wrong.

>>> That could be a Circle, a Rectangle etc.
>>
>> How? The type is Shape. Circle is a different type.
>
> All Shapes have attributes in common. In the example, all Shapes have a
> Draw function.

All shapes have an implementation of Draw and these are all different,
which is the purpose of dispatch. So, again, why Shape must call
Circle's Draw instead of its own?

> I am talking about /how/ things can be done but if you think it's not
> possible then perhaps you can explain how what I am proposing is
> different from single dispatch Liskov substitution - something with
> which I think you agree?

No, you propose meaningless garbage, because differently to C++ you do
not explain when dispatch happens and when not. C++ does it wrong, but
it carefully specifies that wrongness so that the programmer always
knows from the source code when dispatch happens and when not. No riddles.

> Note: "Substitutability is a principle

[...]

LSP is about subtypes. It has nothing to do with the issue at hand. You
did not make your declarations of types straight to even thinking about
whether obtained types are Liskov's or not. Do types first, we can
discuss substitutability after that.

> Or are you just trying to wind me up....? :-(

Good! (:-))

>>
>> [...]
>>
>>> Maybe I've missed something but what I have in mind is that
>>>
>>>    s = shape[i]
>>
>> You missed types, as always. The type of s, should not have been
>> Shape, but "any instance of any type derived from Shape or Shape itself."
>
> In the model I was putting forward an object which has been declared of
> type Shape can be any shape.

That is a class-wide type. Now, how to declare a specific type? You need
a syntax for both.

>>>> Why
>>>>
>>>>     for i in ...
>>>>        shape[i].Draw(CurrentSurface(context))
>>>>
>>>> is not OK and how it would not dispatch?
>>>>
>>>
>>> That looks OK except that I'd store the Surface rather than looking
>>> it up each time.
>>
>> Store? Rendering context cannot be copied, not unless creating a
>> completely independent one.
>
> My example included:
>
>     Surface surf = CurrentSurface(context)
>
> then, later,
>
>     s.Draw(surf)
>
> The variable 'surf' would be a reference and would, in general, take up
> just one word.

Even better. Now you have:

1. Specific type Circle
2. Class-wide type Circle (those can hold any instance of any descendant
of Circle #1)
3. References to Circle #1
4. References to Circle #2

all confused in a huge mess. How do I know that Surface surf is #4 and
not #1?

C++ has several types for references: T&, T*. It conflates specific and
class-wide types, though. The treatment depends on the context and there
is a syntax <type>:: to kill dispatch.

In Ada there is no reference types, because you can simply rename any
object any time. Class-wide and specific types are distinct.

You want to mix #1-#4? Good luck with that!

But this is still all smoke and mirrors on your side. I am still waiting
for an example that does not involve dynamic dispatch!

Remember, one thing at a time:

[x] Dispatch is efficient
[ ] Dispatch is necessary
[ ] Double dispatch is a limited work-around for multiple dispatch

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 10/09/2021 08:42, Dmitry A. Kazakov wrote:
> On 2021-09-09 22:30, James Harris wrote:
>> On 04/09/2021 20:56, Dmitry A. Kazakov wrote:
>>> On 2021-09-04 19:43, James Harris wrote:
>>>> On 03/09/2021 16:46, Dmitry A. Kazakov wrote:
>>>>> On 2021-09-03 16:40, James Harris wrote:
>>>>>> On 03/09/2021 14:39, Dmitry A. Kazakov wrote:
>>>>
>>>> ...
>>>>
>>>>>>> Hash functions are pretty quick.
>>>>>>
>>>>>> Hash functions are not fast enough to find a call target! I was/am
>>>>>> even concerned about the extra cost of following a double pointer.
>>>>>> Using a hash table would be slower still.

....

> Single dispatch = single controlling argument
> Milti-method = several controlling arguments from the same hierarchy
> Full multiple dispatch = several controlling arguments from any hierarchies
>
>> Yes, you spoke about something that could be used in toy situations
>> where you had two or three parameters and a handful of types but it
>> would not scale. If you had just five parameters which could be of a
>> dozen types. You would need a dispatching table of 5^12 or 244 million
>> pointers to who knows how many functions. That is fantasyland.
>
> This is the requirement. Either way, manually or with the compiler
> support, the programmers must do that. You cannot tell the customer, it
> is too many shapes and too many surfaces you put in the requirements. It
> is exactly as many as the customer requested.

I cannot agree. The explosion in the number of potential implementations
is infeasible. My feeling is that a programmer should be made aware of
the ramifications of his decisions and that may make for better code.
For example, although the compiler would see 5^12 potential routines the
programmer may have info the compiler does not and know that not all are
valid.

I can see legitimate compiler-generated dispatching happening on either

1. the first parameter only
2. the first parameter and the result

As discussed elsewhere, single dispatch invoked twice may be
significantly faster than some of the more complex lookups that you
mentioned before.

....

>>>> What is your objection to my proposed solution? To be clear, the
>>>> idea is to have the object's pointer to link directly to the method
>>>> table as follows.
>>>>
>>>>    object:   |___ptr___|___field0___|___field1___| etc
>>>>                   |
>>>>                   V
>>>>              |__type___|__reserved__|__ptr__|__ptr__|__ptr__|__ptr__|
>>>
>>> Show how this is supposed to work with full multiple dispatch, with
>>> multi-methods, with multiple inheritance, with constructors and
>>> destructors, with scalar types.
>>
>> Those are /your/ desires.
>
> The grapes are sour...

The replies are evasive....

:-)

--
James Harris

On 2021-11-26 21:31, James Harris wrote:
> On 10/09/2021 08:42, Dmitry A. Kazakov wrote:

>> This is the requirement. Either way, manually or with the compiler
>> support, the programmers must do that. You cannot tell the customer,
>> it is too many shapes and too many surfaces you put in the
>> requirements. It is exactly as many as the customer requested.
>
> I cannot agree.

Then you don't get the job...

> I can see legitimate compiler-generated dispatching happening on either
>
> 1. the first parameter only
> 2. the first parameter and the result

Nope, the only legitimate parameter is the parameter preceding the last
one if there are four or the last one otherwise...

> As discussed elsewhere, single dispatch invoked twice may be
> significantly faster than some of the more complex lookups that you
> mentioned before.

But nothing can beat a program consisting of the single NOOP instruction.

>>>>> What is your objection to my proposed solution? To be clear, the
>>>>> idea is to have the object's pointer to link directly to the method
>>>>> table as follows.
>>>>>
>>>>>    object:   |___ptr___|___field0___|___field1___| etc
>>>>>                   |
>>>>>                   V
>>>>>              |__type___|__reserved__|__ptr__|__ptr__|__ptr__|__ptr__|
>>>>
>>>> Show how this is supposed to work with full multiple dispatch, with
>>>> multi-methods, with multiple inheritance, with constructors and
>>>> destructors, with scalar types.
>>>
>>> Those are /your/ desires.
>>
>> The grapes are sour...
>
> The replies are evasive....

They are pretty clear. You cannot fulfill the requirements, you are out.
This is the problem with you and Bart. When a customer wants a car, you
try to sell a boat. It is a wonderful boat with shiny polished rowlocks.
You keep on telling how dirty gasoline is and how healthy and emission
free rowing is. Fine, I go to a real car dealer.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 26/11/2021 21:10, Dmitry A. Kazakov wrote:
> On 2021-11-26 21:31, James Harris wrote:
>> On 10/09/2021 08:42, Dmitry A. Kazakov wrote:

....

>> As discussed elsewhere, single dispatch invoked twice may be
>> significantly faster than some of the more complex lookups that you
>> mentioned before.
>
> But nothing can beat a program consisting of the single NOOP instruction.

Yes, it can. A program without the instruction would be faster. :-)

>
>>>>>> What is your objection to my proposed solution? To be clear, the
>>>>>> idea is to have the object's pointer to link directly to the
>>>>>> method table as follows.
>>>>>>
>>>>>>    object:   |___ptr___|___field0___|___field1___| etc
>>>>>>                   |
>>>>>>                   V
>>>>>>              |__type___|__reserved__|__ptr__|__ptr__|__ptr__|__ptr__|
>>>>>
>>>>> Show how this is supposed to work with full multiple dispatch, with
>>>>> multi-methods, with multiple inheritance, with constructors and
>>>>> destructors, with scalar types.
>>>>
>>>> Those are /your/ desires.
>>>
>>> The grapes are sour...
>>
>> The replies are evasive....
>
> They are pretty clear. You cannot fulfill the requirements, you are out.
> This is the problem with you and Bart. When a customer wants a car, you
> try to sell a boat. It is a wonderful boat with shiny polished rowlocks.
> You keep on telling how dirty gasoline is and how healthy and emission
> free rowing is. Fine, I go to a real car dealer.
>

On the contrary, this is a case of responsible design: Don't ask users
what they want; find out what they need.

--
James Harris

On 25/10/2021 20:08, Dmitry A. Kazakov wrote:
> On 2021-10-25 17:33, James Harris wrote:
>> On 25/10/2021 15:34, Dmitry A. Kazakov wrote:
>>> On 2021-10-25 16:04, James Harris wrote:
>>>> On 23/10/2021 20:53, Dmitry A. Kazakov wrote:
>>>>> On 2021-10-23 19:15, James Harris wrote:
>>>>>> On 23/10/2021 12:18, Dmitry A. Kazakov wrote:
>>
>> ...
>>
>>> It is enough to debunk you false claim about inefficiency of dispatch
>>> implementations. One thing at a time.
>>
>> LOL! If that's your goal it helps explain some of your replies!!!
>>
>> And it's a vain hope. You should realise you are wrong! :-)
>
> I presented an implementation of dispatch which complexity is adding
> offset and doing call. Is that inefficient?

No, it's efficient as long as the compiler knows the offset at compile
time. It was operations like your hash search which alarmed me.

>
>>>>>>> provide a code/pseudo-code of drawing shapes from the list
>>>>>>> without knowing specific types and their specific functions like
>>>>>>> surface_A_circle.
>>>>>>>
>>>>>>
>>>>>> OK. HLL:
>>>>>>
>>>>>>    type Circle
>>>>>>      function Draw(Surface S)
>>>>>>         S.DrawCircle(X, Y, R)
>>>>>>      end function
>>>>>>    end type
>>>>>>
>>>>>>    Shape s
>>>>>>    Surface surf = CurrentSurface(context)
>>>>>>    s = shape[i]
>>>>>>    s.Draw(surf)
>>>>>
>>>>> Since s has the type Shape, I presume the declaration
>>>>>
>>>>>     Shape s
>>>>>
>>>>> means that?
>>>>
>>>> Yes.
>>>>
>>>>> So s.Draw must call Draw of the type Shape instead of Draw of the
>>>>> type of the original object, e.g. Circle, Ellipse, Rectangle etc?
>>>>
>>>> No, the intention was that it call Draw of the specific shape
>>>> returned by
>>>>
>>>>    shape[i]
>>>
>>> By reading minds?
>>
>> Er, no, by using the object's tag to locate a vector of routine
>> addresses - as in the code I have posted multiple times.
>
> But you converted the type in assignment. s is Shape, it is not Circle.
> Why on earth it should look after any tags? Oh, each call must always go
> through the vptr? This is what C++ does. It is inefficient and
> semantically wrong.

Rather than straitjacket of superclasses and subclasses and hierarchies
I prefer the more general concept of common interfaces. What matters is
that whether it's a Shape or a Circle or a Regular Dodecagon it has the
expected functions at the expected offsets known at compile time.

Simply put, in this case all Shapes would have a Draw function.

>
>>>> That could be a Circle, a Rectangle etc.
>>>
>>> How? The type is Shape. Circle is a different type.
>>
>> All Shapes have attributes in common. In the example, all Shapes have
>> a Draw function.
>
> All shapes have an implementation of Draw and these are all different,
> which is the purpose of dispatch. So, again, why Shape must call
> Circle's Draw instead of its own?

The Draw function called would be whatever's supplied by the object.

>
>> I am talking about /how/ things can be done but if you think it's not
>> possible then perhaps you can explain how what I am proposing is
>> different from single dispatch Liskov substitution - something with
>> which I think you agree?
>
> No, you propose meaningless garbage, because differently to C++ you do
> not explain when dispatch happens and when not. C++ does it wrong, but
> it carefully specifies that wrongness so that the programmer always
> knows from the source code when dispatch happens and when not. No riddles.

I have tried.

>
>> Note: "Substitutability is a principle
>
> [...]
>
> LSP is about subtypes. It has nothing to do with the issue at hand. You
> did not make your declarations of types straight to even thinking about
> whether obtained types are Liskov's or not. Do types first, we can
> discuss substitutability after that.
>
>> Or are you just trying to wind me up....? :-(
>
> Good! (:-))

LOL! :-)

>
>>>
>>> [...]
>>>
>>>> Maybe I've missed something but what I have in mind is that
>>>>
>>>>    s = shape[i]
>>>
>>> You missed types, as always. The type of s, should not have been
>>> Shape, but "any instance of any type derived from Shape or Shape
>>> itself."
>>
>> In the model I was putting forward an object which has been declared
>> of type Shape can be any shape.
>
> That is a class-wide type. Now, how to declare a specific type? You need
> a syntax for both.

Shape would be an interface. Specific shapes would Circle, Square, etc.
I don't know what problem you are seeing but I cannot see why they could
not be declared as such.

>
>>>>> Why
>>>>>
>>>>>     for i in ...
>>>>>        shape[i].Draw(CurrentSurface(context))
>>>>>
>>>>> is not OK and how it would not dispatch?
>>>>>
>>>>
>>>> That looks OK except that I'd store the Surface rather than looking
>>>> it up each time.
>>>
>>> Store? Rendering context cannot be copied, not unless creating a
>>> completely independent one.
>>
>> My example included:
>>
>>      Surface surf = CurrentSurface(context)
>>
>> then, later,
>>
>>      s.Draw(surf)
>>
>> The variable 'surf' would be a reference and would, in general, take
>> up just one word.
>
> Even better. Now you have:
>
> 1. Specific type Circle
> 2. Class-wide type Circle (those can hold any instance of any descendant
> of Circle #1)
> 3. References to Circle #1
> 4. References to Circle #2
>
> all confused in a huge mess. How do I know that Surface surf is #4 and
> not #1?

No, there are two independent concepts. First, there would be Shapes
that the user would define and manipulate. Second, there would a various
Surfaces on which drawing would take place. Each Surface would provide
various primitives for drawing on itself. Each Shape would use those
primitives to render itself on the Surface.

Simple Shapes such as Circle could draw themselves in one Surface
operation but others such as Widget would invoke multiple Surface
primitives.

>
> C++ has several types for references: T&, T*. It conflates specific and
> class-wide types, though. The treatment depends on the context and there
> is a syntax <type>:: to kill dispatch.
>
> In Ada there is no reference types, because you can simply rename any
> object any time. Class-wide and specific types are distinct.
>
> You want to mix #1-#4? Good luck with that!
>
> But this is still all smoke and mirrors on your side. I am still waiting
> for an example that does not involve dynamic dispatch!

I don't mind dynamic dispatch - as long as it's fast.

>
> Remember, one thing at a time:
>
> [x] Dispatch is efficient
> [ ] Dispatch is necessary
> [ ] Double dispatch is a limited work-around for multiple dispatch
>

[ ] Double dispatch is faster and more scalable than certain forms of
multiple dispatch.

--
James Harris

On 2021-11-27 11:44, James Harris wrote:
> On 25/10/2021 20:08, Dmitry A. Kazakov wrote:
>> On 2021-10-25 17:33, James Harris wrote:
>>> On 25/10/2021 15:34, Dmitry A. Kazakov wrote:
>>>> On 2021-10-25 16:04, James Harris wrote:
>>>>> On 23/10/2021 20:53, Dmitry A. Kazakov wrote:
>>>>>> On 2021-10-23 19:15, James Harris wrote:
>>>>>>> On 23/10/2021 12:18, Dmitry A. Kazakov wrote:
>>>
>>> ...
>>>
>>>> It is enough to debunk you false claim about inefficiency of
>>>> dispatch implementations. One thing at a time.
>>>
>>> LOL! If that's your goal it helps explain some of your replies!!!
>>>
>>> And it's a vain hope. You should realise you are wrong! :-)
>>
>> I presented an implementation of dispatch which complexity is adding
>> offset and doing call. Is that inefficient?
>
> No, it's efficient as long as the compiler knows the offset at compile
> time.

And it does.

>> But you converted the type in assignment. s is Shape, it is not
>> Circle. Why on earth it should look after any tags? Oh, each call must
>> always go through the vptr? This is what C++ does. It is inefficient
>> and semantically wrong.
>
[...]

> Simply put, in this case all Shapes would have a Draw function.

Irrelevant, they must have. Answer the question, why do you want to to
check tag?

>>>>> That could be a Circle, a Rectangle etc.
>>>>
>>>> How? The type is Shape. Circle is a different type.
>>>
>>> All Shapes have attributes in common. In the example, all Shapes have
>>> a Draw function.
>>
>> All shapes have an implementation of Draw and these are all different,
>> which is the purpose of dispatch. So, again, why Shape must call
>> Circle's Draw instead of its own?
>
> The Draw function called would be whatever's supplied by the object.

And how the object can have Draw of a type different that the object's type?

>>>> [...]
>>>>
>>>>> Maybe I've missed something but what I have in mind is that
>>>>>
>>>>>    s = shape[i]
>>>>
>>>> You missed types, as always. The type of s, should not have been
>>>> Shape, but "any instance of any type derived from Shape or Shape
>>>> itself."
>>>
>>> In the model I was putting forward an object which has been declared
>>> of type Shape can be any shape.
>>
>> That is a class-wide type. Now, how to declare a specific type? You
>> need a syntax for both.
>
> Shape would be an interface.

Interface = type.

> Specific shapes would Circle, Square, etc.
> I don't know what problem you are seeing but I cannot see why they could
> not be declared as such.

How do you declare an object that is Circle and never Rectangle?

>> Even better. Now you have:
>>
>> 1. Specific type Circle
>> 2. Class-wide type Circle (those can hold any instance of any
>> descendant of Circle #1)
>> 3. References to Circle #1
>> 4. References to Circle #2
>>
>> all confused in a huge mess. How do I know that Surface surf is #4 and
>> not #1?
>
> No, there are two independent concepts. First, there would be Shapes
> that the user would define and manipulate. Second, there would a various
> Surfaces on which drawing would take place. Each Surface would provide
> various primitives for drawing on itself. Each Shape would use those
> primitives to render itself on the Surface.

Answer the question. 1-4 are clearly different things, how to
distinguish them in the code?

>> C++ has several types for references: T&, T*. It conflates specific
>> and class-wide types, though. The treatment depends on the context and
>> there is a syntax <type>:: to kill dispatch.
>>
>> In Ada there is no reference types, because you can simply rename any
>> object any time. Class-wide and specific types are distinct.
>>
>> You want to mix #1-#4? Good luck with that!
>>
>> But this is still all smoke and mirrors on your side. I am still
>> waiting for an example that does not involve dynamic dispatch!
>
> I don't mind dynamic dispatch - as long as it's fast.

I do not care if you do. You claimed you could do that *without* dynamic
dispatch. Either take that claim back or present code.

>> Remember, one thing at a time:
>>
>> [x] Dispatch is efficient
>> [ ] Dispatch is necessary
>> [ ] Double dispatch is a limited work-around for multiple dispatch
>
> [ ] Double dispatch is faster and more scalable than certain forms of
> multiple dispatch.

Regardless of the truthness of this claim, what prevents you from
implementing corresponding forms same way?

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 27/11/2021 11:16, Dmitry A. Kazakov wrote:
> On 2021-11-27 11:44, James Harris wrote:
>> On 25/10/2021 20:08, Dmitry A. Kazakov wrote:
>>> On 2021-10-25 17:33, James Harris wrote:
>>>> On 25/10/2021 15:34, Dmitry A. Kazakov wrote:
>>>>> On 2021-10-25 16:04, James Harris wrote:
>>>>>> On 23/10/2021 20:53, Dmitry A. Kazakov wrote:
>>>>>>> On 2021-10-23 19:15, James Harris wrote:
>>>>>>>> On 23/10/2021 12:18, Dmitry A. Kazakov wrote:
>>>>
>>>> ...
>>>>
>>>>> It is enough to debunk you false claim about inefficiency of
>>>>> dispatch implementations. One thing at a time.
>>>>
>>>> LOL! If that's your goal it helps explain some of your replies!!!
>>>>
>>>> And it's a vain hope. You should realise you are wrong! :-)
>>>
>>> I presented an implementation of dispatch which complexity is adding
>>> offset and doing call. Is that inefficient?
>>
>> No, it's efficient as long as the compiler knows the offset at compile
>> time.
>
> And it does.
>
>>> But you converted the type in assignment. s is Shape, it is not
>>> Circle. Why on earth it should look after any tags? Oh, each call
>>> must always go through the vptr? This is what C++ does. It is
>>> inefficient and semantically wrong.
>>
> [...]
>
>> Simply put, in this case all Shapes would have a Draw function.
>
> Irrelevant, they must have. Answer the question, why do you want to to
> check tag?

I don't!

Just getting back to this and hopefully some other old threads on
similar topics I am mystified as to what you keep asking me. In the
scheme I was positing an object such as a shape (any shape) would begin
with a pointer to a structure which would include a function table. Each
shape type would have a function table for that type of shape but all
shapes would have a Draw function at the same offset - say offset 40.
Then invocation of Draw for an instance of any Shape type would require
invocation of the function referred to, passing it little more than

1. the instance and
2. the Surface on which it had to render itself.

The Shape's Draw function would invoke one or more Render functions on
the supplied /Surface/.

All Surfaces would have a matching set of rendering primitives (at the
same offsets) for drawing on themselves.

Multiple dispatch would not be needed.

--
James Harris