I am a long way from implementing OO-type objects but I have in mind a
layout for them and something Dmitry mentioned in another thread
suggested that there may be a better way.

My intended model is to have each object's data preceded by a pointer to
a table of its methods. To illustrate, let's say the source code had a
structure 'point' with two fields (x and y) and which referred to two
methods (plot and clear).

Each 'point' would have the coordinates and the two methods mentioned
such that if we had a point P then

P.x would refer to the x coordinate
P.plot() would invoke the plot method

My idea is to implement that as two parts. Each object would have a
read-write part as

pointer to method table
x
y

and the pointer therein would point to a read-only 'method table' which
had the records and some other fields, such as

number of objects pointing at this table
pointer to the type
pointer to procedure 'plot'
pointer to procedure 'clear'

Sorry if that looks a bit complicated. It's about as short as I can
think to make it. Basically, the method table would contain a count of
the number of objects which were pointing at it, a pointer to the type
definition, and a pointer to each method.

I chose it that way to make it fast to dispatch one of the procedures:
follow one pointer to get to the method table then invoke the routine
pointed to by the pointer at the designated offset. (The routine would
be supplied a pointer to the object.)

To get to base info about the type would also be possible by following
the pointer to the type.

Opinions on the scheme?

However Dmitry said: "You do not need length, because it can be deduced
from the tag. Then tag is more universal than a pointer to the table.
Pointer do not work with multiple-dispatch, for example."

Ignoring the length part (as some objects would have their own length
and some would not but that difference is immaterial here) how would a
'tag' system be laid out in memory and how would one use that to locate
a method?

--
James Harris

On 2021-08-29 20:24, James Harris wrote:

> Ignoring the length part (as some objects would have their own length
> and some would not but that difference is immaterial here) how would a
> 'tag' system be laid out in memory and how would one use that to locate
> a method?

You must consider the following inheritance variants:

1. Multiple inheritance (MI)

A B
\ /
C

1.1. Java model. This is when only one parent may have an implementation
(e.g. members). Thus you have a single path where you could keep vptr
[the limited model you have in mind].

1.2. Full MI, C++ model. Any parent may have an implementation. This in
particular means that when you pass C as A you must have vptr of
A'Class, when you pass C as B, you must have another vptr of B'Class.

1.3. Idempotent inheritance:

A
/ \
B C
\ /
D

D has the single instance of A inherited over B and C.

1.4. Additive inheritance:

A
/ \
B C
\ /
D

D has two instances of A, one inherited over B another over C.

2. Multiple dispatch.

2.1. Multimethods only. A multimethod is when all arguments and results
are from the same type hierarchy. E.g. arithmetic operations are
multimethods. Multimethods can have vptr, but the table becomes
multidimensional.

2.2. Parallel inheritance. Arguments can be from different hierarchies,
but only diagonal combinations are allowed:

A1 B1
| |
A2 B2

Foo (A1, B1) - OK
Foo (A1, B2) - not OK
Foo (A2, B2) - OK

This is very common case, e.g. when you have a hierarchy of array
element types parallel to the corresponding array types.

2.3. Full multiple dispatch. Any combinations allowed.

3. Embedded vs. outside tags. If you embed the tag into the object, you
cannot have classes of scalar types.

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

On 29/08/2021 20:24, James Harris wrote:
> I am a long way from implementing OO-type objects but I have in mind a
> layout for them and something Dmitry mentioned in another thread
> suggested that there may be a better way.
>
> My intended model is to have each object's data preceded by a pointer to
> a table of its methods. To illustrate, let's say the source code had a
> structure 'point' with two fields (x and y) and which referred to two
> methods (plot and clear).
>
> Each 'point' would have the coordinates and the two methods mentioned
> such that if we had a point P then
>
>   P.x        would refer to the x coordinate
>   P.plot()   would invoke the plot method
>
> My idea is to implement that as two parts. Each object would have a
> read-write part as
>
>     pointer to method table
>     x
>     y
>
> and the pointer therein would point to a read-only 'method table' which
> had the records and some other fields, such as
>
>     number of objects pointing at this table
>     pointer to the type
>     pointer to procedure 'plot'
>     pointer to procedure 'clear'
>
>
> Sorry if that looks a bit complicated. It's about as short as I can
> think to make it. Basically, the method table would contain a count of
> the number of objects which were pointing at it, a pointer to the type
> definition, and a pointer to each method.
>

So far, that is a straight copy of C++ (without virtual inheritance
support - and it's questionable whether virtual inheritance is useful
enough to justify its complications).

> I chose it that way to make it fast to dispatch one of the procedures:
> follow one pointer to get to the method table then invoke the routine
> pointed to by the pointer at the designated offset. (The routine would
> be supplied a pointer to the object.)
>
> To get to base info about the type would also be possible by following
> the pointer to the type.
>
> Opinions on the scheme?

It works for C++.

On 29/08/2021 19:24, James Harris wrote:
> I am a long way from implementing OO-type objects but I have in mind a
> layout for them and something Dmitry mentioned in another thread
> suggested that there may be a better way.
>
> My intended model is to have each object's data preceded by a pointer to
> a table of its methods. To illustrate, let's say the source code had a
> structure 'point' with two fields (x and y) and which referred to two
> methods (plot and clear).
>
> Each 'point' would have the coordinates and the two methods mentioned
> such that if we had a point P then
>
>   P.x        would refer to the x coordinate
>   P.plot()   would invoke the plot method
>
> My idea is to implement that as two parts. Each object would have a
> read-write part as
>
>     pointer to method table
>     x
>     y
>
> and the pointer therein would point to a read-only 'method table' which
> had the records and some other fields, such as
>
>     number of objects pointing at this table
>     pointer to the type
>     pointer to procedure 'plot'
>     pointer to procedure 'clear'
>
>
> Sorry if that looks a bit complicated. It's about as short as I can
> think to make it. Basically, the method table would contain a count of
> the number of objects which were pointing at it, a pointer to the type
> definition, and a pointer to each method.
>
> I chose it that way to make it fast to dispatch one of the procedures:
> follow one pointer to get to the method table then invoke the routine
> pointed to by the pointer at the designated offset. (The routine would
> be supplied a pointer to the object.)
>
> To get to base info about the type would also be possible by following
> the pointer to the type.
>
> Opinions on the scheme?
>
> However Dmitry said: "You do not need length, because it can be deduced
> from the tag. Then tag is more universal than a pointer to the table.
> Pointer do not work with multiple-dispatch, for example."
>
> Ignoring the length part (as some objects would have their own length
> and some would not but that difference is immaterial here) how would a
> 'tag' system be laid out in memory and how would one use that to locate
> a method?
>

I haven't implemented this stuff in static code: classes with methods
and with inheritance, so can't speak directly from experience.

I have played with it however, and I have implemented it for dynamic code.

The first thing that strikes me, if I understood correctly, is that each
instance of a Point needs to include not only the data x,y, but also a
pointer.

With apparently, exactly the same pointer in each of millions of
instances. Which all means that if you allocate an array of such points,
you can't just initialise them with all-zeros to (0,0), but need to
specifically initialise that pointer field in each one.

So, why is that actually necessary? Is it because of inheritance, where
any instance P could be of the base class, or of a derived class which
could have its own sets of methods, and this information is not known
until runtime?

I can illustrate that with this example in dynamic code:

record point =
var x,y
proc plot(&self) =
println "POINT",self.x,self.y
end
end

record dirvec(point) = # inherit from Point
proc plot(&self) =
println "DIRVEC",self.x,self.y
end
end

proc start=
a:=point(10,20)
b:=dirvec(30,30)

a.plot()
b.plot()
end

The output here is:

POINT 10 20
DIRVEC 30 30

Each instance (A and B), contains values for its X and Y fields. But no
pointers to method tables. But they both have, because it is dynamic, is
a type tag: a index into tables of types.

That is used to search (again because its dynamic), a table of entries
for the 'plot' attribute (which can be used in a different other types
too), which matches the types of A and B.

I would have expect a static language to convert those last the lines to:

point.plot(a)
dirvec.plot(b)

I guess it depends on how A and B would be declared, and whether, if
they have those two different types, either can still be passed to a
function taking a Point type, and possibly one taking a Dirvec type.

(I think I ran into trouble trying this in static code, not just because
of methods, but because the two types instances would have the normal
fields at different offsets, and could be different types; say Point has
int32 X,Y, but Dirvec defines float64 Y,Z and inherits int32 X.

But maybe I'm just not understanding how OOP is supposed to work.)

On 29/08/2021 20:32, Dmitry A. Kazakov wrote:
> On 2021-08-29 20:24, James Harris wrote:
>
>> Ignoring the length part (as some objects would have their own length
>> and some would not but that difference is immaterial here) how would a
>> 'tag' system be laid out in memory and how would one use that to
>> locate a method?
>
> You must consider the following inheritance variants:

....

Thanks for the information, Dmitry. I might come back to you about some
of that. But for this thread I was wondering how the memory might be
laid out under the tag model that you mentioned. What form does a tag
take and how does the runtime get from the tag to a method?

If it depends on which model is in use then what about single
inheritance and the Full MI model you mentioned?

--
James Harris

On 29/08/2021 23:04, Bart wrote:
> On 29/08/2021 19:24, James Harris wrote:
>> I am a long way from implementing OO-type objects but I have in mind a
>> layout for them and something Dmitry mentioned in another thread
>> suggested that there may be a better way.
>>
>> My intended model is to have each object's data preceded by a pointer
>> to a table of its methods.

....

>>
>> However Dmitry said: "You do not need length, because it can be
>> deduced from the tag. Then tag is more universal than a pointer to the
>> table. Pointer do not work with multiple-dispatch, for example."

....

> I haven't implemented this stuff in static code: classes with methods
> and with inheritance, so can't speak directly from experience.
>
> I have played with it however, and I have implemented it for dynamic code.
>
> The first thing that strikes me, if I understood correctly, is that each
> instance of a Point needs to include not only the data x,y, but also a
> pointer.
>
> With apparently, exactly the same pointer in each of millions of
> instances. Which all means that if you allocate an array of such points,
> you can't just initialise them with all-zeros to (0,0), but need to
> specifically initialise that pointer field in each one.
>
> So, why is that actually necessary? Is it because of inheritance, where
> any instance P could be of the base class, or of a derived class which
> could have its own sets of methods, and this information is not known
> until runtime?

It's not because of inheritance. It's to support polymorphism.

Without OO there would be no 'method table pointer' (MTP). Instead, each
function called to act on an object would know the object's type and,
hence, where its fields are.

With OO the object could be one of a number of different types as long
as they all have the same conceptual set of functions (in the same
internal order), e.g. they both have a plot() function or they both have
an add() function. So you could have

pixel_point P
float_point F

Both types could have a plot() function. As long as it had the same
interface then the function could be invoked by

P.plot()
F.plot()

The key benefit, AISI, is that the routine which calls plot would work
with either type of point. The call wouldn't care what form the point
took; it would be polymorphic.

Of course, whether that's worth the complexity of the implementation is
debatable but it does allow a lot of source code to be simpler.

>
> I can illustrate that with this example in dynamic code:
>
>     record point =
>         var x,y
>         proc plot(&self) =
>             println "POINT",self.x,self.y
>         end
>     end
>
>     record dirvec(point) =        # inherit from Point
>         proc plot(&self) =
>             println "DIRVEC",self.x,self.y
>         end
>     end
>
>     proc start=
>         a:=point(10,20)
>         b:=dirvec(30,30)
>
>         a.plot()
>         b.plot()
>     end
>
> The output here is:
>
>     POINT 10 20
>     DIRVEC 30 30
>
> Each instance (A and B), contains values for its X and Y fields. But no
> pointers to method tables. But they both have, because it is dynamic, is
> a type tag: a index into tables of types.

So your form of a tag is an index into a table? Maybe that's how
Dmitry's 'tag' would be implemented.

I have doubts about indexing into a table rather than pointing to the
method table directly. It would probably require at least one extra
level of dereferencing to find a method.

>
> That is used to search (again because its dynamic), a table of entries
> for the 'plot' attribute (which can be used in a different other types
> too), which matches the types of A and B.
>
> I would have expect a static language to convert those last the lines to:
>
>    point.plot(a)
>    dirvec.plot(b)

Why not

a.plot()
b.plot()

?

>
> I guess it depends on how A and B would be declared, and whether, if
> they have those two different types, either can still be passed to a
> function taking a Point type, and possibly one taking a Dirvec type.
>
> (I think I ran into trouble trying this in static code, not just because
> of methods, but because the two types instances would have the normal
> fields at different offsets, and could be different types; say Point has
> int32 X,Y, but Dirvec defines float64 Y,Z and inherits int32 X.
>
> But maybe I'm just not understanding how OOP is supposed to work.)

Dmitry's reply about various different interpretations of how OOP can
work shows there is no single right answer. Indeed, OOP may not be the
best solution, at all.

--
James Harris

On 30/08/2021 12:23, James Harris wrote:
> On 29/08/2021 23:04, Bart wrote:
>> On 29/08/2021 19:24, James Harris wrote:
>>> I am a long way from implementing OO-type objects but I have in mind
>>> a layout for them and something Dmitry mentioned in another thread
>>> suggested that there may be a better way.
>>>
>>> My intended model is to have each object's data preceded by a pointer
>>> to a table of its methods.
>
> ...
>
>>>
>>> However Dmitry said: "You do not need length, because it can be
>>> deduced from the tag. Then tag is more universal than a pointer to
>>> the table. Pointer do not work with multiple-dispatch, for example."
>
> ...
>
>> I haven't implemented this stuff in static code: classes with methods
>> and with inheritance, so can't speak directly from experience.
>>
>> I have played with it however, and I have implemented it for dynamic
>> code.
>>
>> The first thing that strikes me, if I understood correctly, is that
>> each instance of a Point needs to include not only the data x,y, but
>> also a pointer.
>>
>> With apparently, exactly the same pointer in each of millions of
>> instances. Which all means that if you allocate an array of such
>> points, you can't just initialise them with all-zeros to (0,0), but
>> need to specifically initialise that pointer field in each one.
>>
>> So, why is that actually necessary? Is it because of inheritance,
>> where any instance P could be of the base class, or of a derived class
>> which could have its own sets of methods, and this information is not
>> known until runtime?
>
> It's not because of inheritance. It's to support polymorphism.

In particular, it is for support of run-time polymorphism.

There is also compile-time polymorphism, handled by templates or other
generic coding mechanisms. Since the types are determined entirely at
compile time, there is no need for a pointer to a virtual method table
and like C++ classes without virtual methods, there is no need for the
extra pointer in the class implementation. (Obviously compile-time
polymorphism has limitations of flexibility, but it results in more
efficient code.)

I often use inheritance in C++ without virtual methods, and therefore no
virtual method table overhead in the classes (and no possibility of
run-time polymorphism).

>
> Without OO there would be no 'method table pointer' (MTP). Instead, each
> function called to act on an object would know the object's type and,
> hence, where its fields are.
>
> With OO the object could be one of a number of different types as long
> as they all have the same conceptual set of functions (in the same
> internal order), e.g. they both have a plot() function or they both have
> an add() function. So you could have
>
>   pixel_point P
>   float_point F
>
> Both types could have a plot() function. As long as it had the same
> interface then the function could be invoked by
>
>   P.plot()
>   F.plot()
>
> The key benefit, AISI, is that the routine which calls plot would work
> with either type of point. The call wouldn't care what form the point
> took; it would be polymorphic.
>
> Of course, whether that's worth the complexity of the implementation is
> debatable but it does allow a lot of source code to be simpler.
>

<https://en.wikipedia.org/wiki/Virtual_method_table>

You are describing exactly the system used in many compiled object
oriented languages.

But you should be aware that compile-time polymorphism has become the
current trend, giving more efficient results in many cases.

>>
>> I can illustrate that with this example in dynamic code:
>>
>>      record point =
>>          var x,y
>>          proc plot(&self) =
>>              println "POINT",self.x,self.y
>>          end
>>      end
>>
>>      record dirvec(point) =        # inherit from Point
>>          proc plot(&self) =
>>              println "DIRVEC",self.x,self.y
>>          end
>>      end
>>
>>      proc start=
>>          a:=point(10,20)
>>          b:=dirvec(30,30)
>>
>>          a.plot()
>>          b.plot()
>>      end
>>
>> The output here is:
>>
>>      POINT 10 20
>>      DIRVEC 30 30
>>
>> Each instance (A and B), contains values for its X and Y fields. But
>> no pointers to method tables. But they both have, because it is
>> dynamic, is a type tag: a index into tables of types.
>

That code is not dynamic polymorphism - the types are all statically
known at compile time. Dynamic polymorphism would be if you also had:

proc doubleplot(&x) =
x.plot();
x.plot();
end

proc start =
a : =point(10, 20)
b := dirvec(30, 30)
doubleplot(&a)
doubleplot(&b)
end

i.e., the function "doubleplot" is compiled without knowing whether it
will be calling the "point" version of "plot", or the "dirvec" version.

> So your form of a tag is an index into a table? Maybe that's how
> Dmitry's 'tag' would be implemented.

That's what it sounds like to me. I don't see off-hand any significant
benefits of using an index into a table, rather than a pointer directly
to the type information (primarily the virtual methods list, but perhaps
also containing run-time type information if the language supports taht).

>
> I have doubts about indexing into a table rather than pointing to the
> method table directly. It would probably require at least one extra
> level of dereferencing to find a method.
>

The extra level of indirection could be removed if you are doing
whole-program code generation, but you'd still need to scale the index
and add it to the base of the table instead of using the pointer directly.

>>
>> That is used to search (again because its dynamic), a table of entries
>> for the 'plot' attribute (which can be used in a different other types
>> too), which matches the types of A and B.
>>
>> I would have expect a static language to convert those last the lines to:
>>
>>     point.plot(a)
>>     dirvec.plot(b)
>
> Why not
>
>   a.plot()
>   b.plot()
>
> ?

Perhaps Bart meant the static language would implement "a.plot()" as
though it had been "point.plot(a)", which is exactly how optimising
compilers /do/ implement polymorphism when they know the types at
compile time. (These applies to virtual methods too - it's called
devirtualisation optimisation.)

>
>>
>> I guess it depends on how A and B would be declared, and whether, if
>> they have those two different types, either can still be passed to a
>> function taking a Point type, and possibly one taking a Dirvec type.
>>
>> (I think I ran into trouble trying this in static code, not just
>> because of methods, but because the two types instances would have the
>> normal fields at different offsets, and could be different types; say
>> Point has int32 X,Y, but Dirvec defines float64 Y,Z and inherits int32 X.
>>
>> But maybe I'm just not understanding how OOP is supposed to work.)
>
> Dmitry's reply about various different interpretations of how OOP can
> work shows there is no single right answer. Indeed, OOP may not be the
> best solution, at all.
>

Yes. Your job here is to listen to all the ideas, and figure out what
will work for /you/ and /your/ language.

On 2021-08-30 11:47, James Harris wrote:
> On 29/08/2021 20:32, Dmitry A. Kazakov wrote:
>> On 2021-08-29 20:24, James Harris wrote:
>>
>>> Ignoring the length part (as some objects would have their own length
>>> and some would not but that difference is immaterial here) how would
>>> a 'tag' system be laid out in memory and how would one use that to
>>> locate a method?
>>
>> You must consider the following inheritance variants:
>
> ...
>
> Thanks for the information, Dmitry. I might come back to you about some
> of that. But for this thread I was wondering how the memory might be
> laid out under the tag model that you mentioned. What form does a tag
> take and how does the runtime get from the tag to a method?

You must also consider type tests. E.g. is A a descendant of B, unrelated?

> If it depends on which model is in use then what about single
> inheritance and the Full MI model you mentioned?

In the most general case a dispatching table belongs to the method, not
to the type. The tag would denote an N-th coordinate (plane) of the
multidimensional index in the table.

E.g. in the case of full dispatch: Print (Device, Shape), Print is a
method of two hierarchies.

Now, of course, because the same tag must be used to index a multitude
of tables, it cannot be a dense index. So, go figure.

Another issue to consider is whether tables are contiguous. Consider the
following scenario:

The type A is declared in the shared library libA. So you can put the
dispatching table there? Not so fast. Let there be the library libB,
that derives some B from A. That must change the dispatching tables for
A upon loading of libB. When unloading libB you must roll the changes back.

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

On 30/08/2021 11:23, James Harris wrote:
> On 29/08/2021 23:04, Bart wrote:

>> So, why is that actually necessary? Is it because of inheritance,
>> where any instance P could be of the base class, or of a derived class
>> which could have its own sets of methods, and this information is not
>> known until runtime?
>
> It's not because of inheritance. It's to support polymorphism.
>
> Without OO there would be no 'method table pointer' (MTP). Instead, each
> function called to act on an object would know the object's type and,
> hence, where its fields are.
>
> With OO the object could be one of a number of different types as long
> as they all have the same conceptual set of functions (in the same
> internal order), e.g. they both have a plot() function or they both have
> an add() function. So you could have
>
>   pixel_point P
>   float_point F
>
> Both types could have a plot() function. As long as it had the same
> interface then the function could be invoked by
>
>   P.plot()
>   F.plot()
>
> The key benefit, AISI, is that the routine which calls plot would work
> with either type of point. The call wouldn't care what form the point
> took; it would be polymorphic.

That example looks too simple to me; it doesn't really involve OO in my
opinion as it merely provides a convenient alternative syntax. Example
in static code:

record pixelpoint =
byte x,y
proc plot(pixelpoint &self)=
println "Pixelpoint:",self.x,self.y
end
end

record floatpoint =
real x,y
proc plot(floatpoint &self)=
println "Floatpoint:",self.x,self.y
end
end

proc start=
pixelpoint p:=(10,20)
floatpoint q:=(30.5,40.6)

p.plot()
q.plot()
println p.bytes, q.bytes
end

Output is:

Pixelpoint: 10 20
Floatpoint: 30.500000 40.600000
2 16

That p.plot() line is just an alternative to pixelpoint.plot(p), with
the transformation done at compile-time. Here, this is just
encapsulation (which I actually never use; I'm surprised it works!).

I'm not up on OO terms, but polymorphism to me would mean function and
operator overloading. So if you had two functions both called plot,
taking pixelpoint or floatpoint parameters respectively, you could say:

plot(p)
plot(f)

>> Each instance (A and B), contains values for its X and Y fields. But
>> no pointers to method tables. But they both have, because it is
>> dynamic, is a type tag: a index into tables of types.
>
> So your form of a tag is an index into a table? Maybe that's how
> Dmitry's 'tag' would be implemented.

That's just generally how it works with dynamic typing; the tag is the
key to everything. However such code usually means dynamic type dispatch
which is slow. If you have static typing at all, you expect it to be
much faster.

> I have doubts about indexing into a table rather than pointing to the
> method table directly. It would probably require at least one extra
> level of dereferencing to find a method.

Why, in your example, wouldn't the compiler know the type of P?

Do you have a more elaborate example that shows off the advantages of
OO, or whatever you are trying to do, that would be too clunky in C?

On 30/08/2021 12:19, David Brown wrote:
> On 30/08/2021 12:23, James Harris wrote:
>> On 29/08/2021 23:04, Bart wrote:

>>> I can illustrate that with this example in dynamic code:

> That code is not dynamic polymorphism - the types are all statically
> known at compile time. Dynamic polymorphism would be if you also had:
>
> proc doubleplot(&x) =
> x.plot();
> x.plot();
> end
>
> proc start =
> a := point(10, 20)
> b := dirvec(30, 30)
> doubleplot(&a)
> doubleplot(&b)
> end
>
> i.e., the function "doubleplot" is compiled without knowing whether it
> will be calling the "point" version of "plot", or the "dirvec" version.

This works fine (but the &s are not needed). But since this is a
dynamically typed language where you get generics and everything else
for free, that is not surprising.

I was making a point about what information needs to be stored with each
instance. Sometimes I don't even need the tag for every point value:

type point = struct
int32 x,y
end

proc start =
x:=new(array,point, 1 million)
println x.bytes
print x[12345]
end

Output is:

8000000
(0,0)

However the 'struct' type doesn't have methods. That is just because the
language decided not to allow that; it could have done, and each array
element would still need only 8 bytes (the array object itself has a tag
and knows the type of the elements).

But it still knows how to print the type! (For a custom print function,
here I'd favour an overload of 'tostring' for this point type, then I
can just do a regular 'print'.)

On 2021-08-30 13:19, David Brown wrote:

> There is also compile-time polymorphism, handled by templates or other
> generic coding mechanisms.

Yes, but static polymorphism has a very limited use because you cannot
have objects from the closure of the class, only instances of specific
type ones. In practice this precludes most cases of reuse.

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

On 30/08/2021 12:36, Dmitry A. Kazakov wrote:
> On 2021-08-30 11:47, James Harris wrote:
>> On 29/08/2021 20:32, Dmitry A. Kazakov wrote:
>>> On 2021-08-29 20:24, James Harris wrote:
>>>
>>>> Ignoring the length part (as some objects would have their own
>>>> length and some would not but that difference is immaterial here)
>>>> how would a 'tag' system be laid out in memory and how would one use
>>>> that to locate a method?
>>>
>>> You must consider the following inheritance variants:
>>
>> ...
>>
>> Thanks for the information, Dmitry. I might come back to you about
>> some of that. But for this thread I was wondering how the memory might
>> be laid out under the tag model that you mentioned. What form does a
>> tag take and how does the runtime get from the tag to a method?
>
> You must also consider type tests. E.g. is A a descendant of B, unrelated?

Interesting question...!

>
>> If it depends on which model is in use then what about single
>> inheritance and the Full MI model you mentioned?
>
> In the most general case a dispatching table belongs to the method, not
> to the type. The tag would denote an N-th coordinate (plane) of the
> multidimensional index in the table.

That sounds weird. If the dispatch table belongs to the method what
would it be indexed by?

When you talk about a tag do you mean something that might, if it cannot
be optimised any better, result in a series of three or even more
lookups executed at run time before the required method is found?

>
> E.g. in the case of full dispatch: Print (Device, Shape), Print is a
> method of two hierarchies.
>
> Now, of course, because the same tag must be used to index a multitude
> of tables, it cannot be a dense index. So, go figure.
>
> Another issue to consider is whether tables are contiguous. Consider the
> following scenario:
>
> The type A is declared in the shared library libA. So you can put the
> dispatching table there? Not so fast. Let there be the library libB,
> that derives some B from A. That must change the dispatching tables for
> A upon loading of libB. When unloading libB you must roll the changes back.

It's rare that a good idea is so complex or has so many semantically
different implementations. I do wonder whether all this complexity
should be replaced by something simpler.

My current scheme is simpler but it doesn't necessarily have
substitutability which is something I gather you believe to be
important, even from your interesting question, above.

--
James Harris

On 2021-08-30 22:25, James Harris wrote:
> On 30/08/2021 12:36, Dmitry A. Kazakov wrote:
>> On 2021-08-30 11:47, James Harris wrote:
>>> On 29/08/2021 20:32, Dmitry A. Kazakov wrote:
>>>> On 2021-08-29 20:24, James Harris wrote:
>>>>
>>>>> Ignoring the length part (as some objects would have their own
>>>>> length and some would not but that difference is immaterial here)
>>>>> how would a 'tag' system be laid out in memory and how would one
>>>>> use that to locate a method?
>>>>
>>>> You must consider the following inheritance variants:
>>>
>>> ...
>>>
>>> Thanks for the information, Dmitry. I might come back to you about
>>> some of that. But for this thread I was wondering how the memory
>>> might be laid out under the tag model that you mentioned. What form
>>> does a tag take and how does the runtime get from the tag to a method?
>>
>> You must also consider type tests. E.g. is A a descendant of B,
>> unrelated?
>
> Interesting question...!
>
>>
>>> If it depends on which model is in use then what about single
>>> inheritance and the Full MI model you mentioned?
>>
>> In the most general case a dispatching table belongs to the method,
>> not to the type. The tag would denote an N-th coordinate (plane) of
>> the multidimensional index in the table.
>
> That sounds weird. If the dispatch table belongs to the method what
> would it be indexed by?

By the type, of course. It is pretty straightforward. Consider

Surface Shape
/ \ / \
PDF SVG Ellipse Rectangle

Draw | PDF | SVG |
----------+-----+-----+
Ellipse | ptr | ptr |
----------+-----+-----+
Rectangle | ptr | ptr |
----------+-----+-----+

> When you talk about a tag do you mean something that might, if it cannot
> be optimised any better, result in a series of three or even more
> lookups executed at run time before the required method is found?

Yes. You need some unique type identifier, short enough to fit in a
register.

>> Another issue to consider is whether tables are contiguous. Consider
>> the following scenario:
>>
>> The type A is declared in the shared library libA. So you can put the
>> dispatching table there? Not so fast. Let there be the library libB,
>> that derives some B from A. That must change the dispatching tables
>> for A upon loading of libB. When unloading libB you must roll the
>> changes back.
>
> It's rare that a good idea is so complex or has so many semantically
> different implementations. I do wonder whether all this complexity
> should be replaced by something simpler.

It is a very complex issue. E.g. consider requirements:

1. All slots in a dispatching table are always defined, i.e. dispatch
never fail at run-time.

1.1. That would require the user to override slots the language cannot
safely inherit from the parent type, e.g. mixed type operations.

1.2. The problem with modules. Let the module X derive HTML from Surface
and the module Y derive Sector from Shape. If neither of the modules
uses/knows another, where to define Draw (HTML, Sector)?

There must be some solution for where to place methods. BTW, C++ model
when methods are put into classes is clearly inconsistent with multiple
dispatch. Where to place Draw?

2. No object of a type may exist after the type ceases to exist.

3. Dispatch never happens on partially constructed/destructed objects.
Consider:

A
|
B

In the constructor of B is called after A is constructed. Now what
happens if you dispatch to Foo from the constructor of A and Foo is
overridden by B?

C++ "resolves" that by refusing to dispatch. It will call A::Foo instead
of B::Foo.

That is no solution because programmers do need dispatching
constructors/destructors. A possible solution would be to have
constructors/destructors of class-wide objects where you could safely
dispatch from.

4. Allowing or not to re-dispatch. I.e. if you dispatch on Foo, can you
dispatch again on the same argument inside Foo? This is how C++ works
and this is greatly inefficient and also inconsistent with the types.

> My current scheme is simpler but it doesn't necessarily have
> substitutability which is something I gather you believe to be
> important, even from your interesting question, above.

Inheritance is an open issue. I do not know any language that handles it
consistently and complete. So you have a chance to invent something useful.

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

On 30/08/2021 22:13, Dmitry A. Kazakov wrote:
> On 2021-08-30 22:25, James Harris wrote:
>> On 30/08/2021 12:36, Dmitry A. Kazakov wrote:

....

>>> In the most general case a dispatching table belongs to the method,
>>> not to the type. The tag would denote an N-th coordinate (plane) of
>>> the multidimensional index in the table.
>>
>> That sounds weird. If the dispatch table belongs to the method what
>> would it be indexed by?
>
> By the type, of course. It is pretty straightforward. Consider
>
>    Surface       Shape
>      /  \         /  \
>    PDF  SVG  Ellipse  Rectangle
>
>    Draw      | PDF | SVG |
>    ----------+-----+-----+
>    Ellipse   | ptr | ptr |
>    ----------+-----+-----+
>    Rectangle | ptr | ptr |
>    ----------+-----+-----+

That solution looks as though the shapes would have to know how to draw
themselves on different surfaces. As such I doubt it would scale well as
new shapes and new types of surface were added. But maybe it's purely
illustrative of multiple dispatch. What I take from it is that, however
it's done, the address of the drawing function (the ptr in the above
table) would need to be found from a key of three parameters

(shape type, surface type, function name)

whereas single dispatch would find a function based on two parameters
such as

(shape type, function name)

Is that correct?

>
>> When you talk about a tag do you mean something that might, if it
>> cannot be optimised any better, result in a series of three or even
>> more lookups executed at run time before the required method is found?
>
> Yes. You need some unique type identifier, short enough to fit in a
> register.

If the tag is the unique identifier you mention how would the compiled
code get from the tag to the correct routine?

My intention was for the tag to be the address of the dispatch table so
that functions (as long as they were at known offsets) could be accessed
quickly but I don't think you liked that.

I will have to come back to you on the other points of your post.

--
James Harris

On 2021-09-03 14:27, James Harris wrote:
> On 30/08/2021 22:13, Dmitry A. Kazakov wrote:
>> On 2021-08-30 22:25, James Harris wrote:
>>> On 30/08/2021 12:36, Dmitry A. Kazakov wrote:
>
> ...
>
>>>> In the most general case a dispatching table belongs to the method,
>>>> not to the type. The tag would denote an N-th coordinate (plane) of
>>>> the multidimensional index in the table.
>>>
>>> That sounds weird. If the dispatch table belongs to the method what
>>> would it be indexed by?
>>
>> By the type, of course. It is pretty straightforward. Consider
>>
>>     Surface       Shape
>>       /  \         /  \
>>     PDF  SVG  Ellipse  Rectangle
>>
>>     Draw      | PDF | SVG |
>>     ----------+-----+-----+
>>     Ellipse   | ptr | ptr |
>>     ----------+-----+-----+
>>     Rectangle | ptr | ptr |
>>     ----------+-----+-----+
>
> That solution looks as though the shapes would have to know how to draw
> themselves on different surfaces. As such I doubt it would scale well as
> new shapes and new types of surface were added. But maybe it's purely
> illustrative of multiple dispatch. What I take from it is that, however
> it's done, the address of the drawing function (the ptr in the above
> table) would need to be found from a key of three parameters
>
>   (shape type, surface type, function name)
>
> whereas single dispatch would find a function based on two parameters
> such as
>
>   (shape type, function name)
>
> Is that correct?

Yes, and the surface parameter is then class-wide, i.e. each function
must have to deal with any shape (any instance from the class = class-wide).

>>> When you talk about a tag do you mean something that might, if it
>>> cannot be optimised any better, result in a series of three or even
>>> more lookups executed at run time before the required method is found?
>>
>> Yes. You need some unique type identifier, short enough to fit in a
>> register.
>
> If the tag is the unique identifier you mention how would the compiled
> code get from the tag to the correct routine?

Via the dispatching table indexed by the tag. Tag could not be a dense
index, true, so you would use a hash or binary search instead.

> My intention was for the tag to be the address of the dispatch table so
> that functions (as long as they were at known offsets) could be accessed
> quickly but I don't think you liked that.

Hash functions are pretty quick.

Then again, if you don't repeat C++ and Java error confusing class-wide
and specific types, you would drastically reduce cases when dispatch
ever happens. Most of the code deals with statically known specific
types, ergo, no dispatch (or as some call it, "static dispatch").

Segmented dispatching tables is IMO a bigger problem unless you rebuild
affected dispatching each time you load a library or dynamically create
a new type etc.

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

On 03/09/2021 13:27, James Harris wrote:
> On 30/08/2021 22:13, Dmitry A. Kazakov wrote:
>> On 2021-08-30 22:25, James Harris wrote:
>>> On 30/08/2021 12:36, Dmitry A. Kazakov wrote:
>
> ...
>
>>>> In the most general case a dispatching table belongs to the method,
>>>> not to the type. The tag would denote an N-th coordinate (plane) of
>>>> the multidimensional index in the table.
>>>
>>> That sounds weird. If the dispatch table belongs to the method what
>>> would it be indexed by?
>>
>> By the type, of course. It is pretty straightforward. Consider
>>
>>     Surface       Shape
>>       /  \         /  \
>>     PDF  SVG  Ellipse  Rectangle
>>
>>     Draw      | PDF | SVG |
>>     ----------+-----+-----+
>>     Ellipse   | ptr | ptr |
>>     ----------+-----+-----+
>>     Rectangle | ptr | ptr |
>>     ----------+-----+-----+
>
> That solution looks as though the shapes would have to know how to draw
> themselves on different surfaces. As such I doubt it would scale well as
> new shapes and new types of surface were added. But maybe it's purely
> illustrative of multiple dispatch.

(The example reminds me of actual drawing code I needed to write in my
applications in the 1990s. The script language included functions such
as a general-purpose one called Plot(), with 8 parameters (many optional
with defaults). The remaining docs are poor but I think they were:

Dest Destination code
D Info specific to a destination
Scan Scan type
View View point
P Drawing element
Clear Whether to clear destination first
Nsegments 1, or build results as multiple hoz bands
Flags Misc

This is for displaying a 3D model, which is represented in P as a
hierarchical tree of drawing elements. There were nearly 50 leaf objects
(including Rectangle and Ellipse!) plus named collections which in a HLL
would correspond to a named function call.

Dest is a code broadly indicating one of Window, Image, Printer/Plotter,
or collections of 3D Face or Lines. Here D might refer to the actual
window, a filename to capture output (eg. EPS print format) etc.

Scan indicates how the data should be processed, with 16 variations,
including Wireframe, Hidden, Shaded, Erase, Highlight, DXF dest, Expand
to lines/faces, ...

View specifies the viewpoint from which the result will be rendered, and
whether it uses perspective projection.

Flags controls many other factors: whether to draw grids or axes, page
outlines ...

OK, the example was clearly a simple one to illustrate some aspects of
how OOP works. But I see such examples using shapes all the time and
find them somewhat annoying.

It gives the impression that OOP can magically solve all the problems
that come up in actual applications, but the reality is always a lot
more complicated.

I'm rather sceptical about what OOP can do, and I have firm views on how
far a language should get involved in matters that should be the concern
of an application.

I also think that, if you really want to use OOP seriously, then you're
quite liable to just end up reinventing C++, as you meet the same
obstacles.)

What I take from it is that, however
> it's done, the address of the drawing function (the ptr in the above
> table) would need to be found from a key of three parameters
>
>   (shape type, surface type, function name)
>
> whereas single dispatch would find a function based on two parameters
> such as
>
>   (shape type, function name)
>
> Is that correct?

The shape should describe the shape itself and nothing else. If you want
to plot it, then extra information is needed:

p.plot(surface_type)

With perhaps that parameter being optional when there is a sensible
default. So here there is single dispatch based on shape type.

Anything else would be difficult to get your head around. If there are M
shape types and N surface types, then you've got MxN methods to write,
but where are you going to write them? Functions are written one after
the other, not in a table!

You might consider introducing overloaded functions, so the plot()
method for Rectangle is split into one each for PDF and SVG. Feature creep.

(My approach as I used was single dispatch - a simple switch - using
common code to reduce complex objects to basic edges, and then using
single dispatch on the 'surface' when drawing those edges.)

On 03/09/2021 14:39, Dmitry A. Kazakov wrote:
> On 2021-09-03 14:27, James Harris wrote:
>> On 30/08/2021 22:13, Dmitry A. Kazakov wrote:
>>> On 2021-08-30 22:25, James Harris wrote:
>>>> On 30/08/2021 12:36, Dmitry A. Kazakov wrote:
>>
>> ...
>>
>>>>> In the most general case a dispatching table belongs to the method,
>>>>> not to the type. The tag would denote an N-th coordinate (plane) of
>>>>> the multidimensional index in the table.
>>>>
>>>> That sounds weird. If the dispatch table belongs to the method what
>>>> would it be indexed by?
>>>
>>> By the type, of course. It is pretty straightforward. Consider
>>>
>>>     Surface       Shape
>>>       /  \         /  \
>>>     PDF  SVG  Ellipse  Rectangle
>>>
>>>     Draw      | PDF | SVG |
>>>     ----------+-----+-----+
>>>     Ellipse   | ptr | ptr |
>>>     ----------+-----+-----+
>>>     Rectangle | ptr | ptr |
>>>     ----------+-----+-----+
>>
>> That solution looks as though the shapes would have to know how to
>> draw themselves on different surfaces. As such I doubt it would scale
>> well as new shapes and new types of surface were added. But maybe it's
>> purely illustrative of multiple dispatch. What I take from it is that,
>> however it's done, the address of the drawing function (the ptr in the
>> above table) would need to be found from a key of three parameters
>>
>>    (shape type, surface type, function name)
>>
>> whereas single dispatch would find a function based on two parameters
>> such as
>>
>>    (shape type, function name)
>>
>> Is that correct?
>
> Yes, and the surface parameter is then class-wide, i.e. each function
> must have to deal with any shape (any instance from the class =
> class-wide).

OK. I am now trying to understand what you mean by 'class wide'. Are you
saying that each drawing function would have to be passed the target
surface as a parameter - and that makes surface 'class wide'?

In practice, I'd imagine it's best for 'surfaces' to know how to draw on
themselves and they would export drawing primitives (such as point,
line, curve, rectangle, ellipse etc) which routines can call.

>
>>>> When you talk about a tag do you mean something that might, if it
>>>> cannot be optimised any better, result in a series of three or even
>>>> more lookups executed at run time before the required method is found?
>>>
>>> Yes. You need some unique type identifier, short enough to fit in a
>>> register.
>>
>> If the tag is the unique identifier you mention how would the compiled
>> code get from the tag to the correct routine?
>
> Via the dispatching table indexed by the tag. Tag could not be a dense
> index, true, so you would use a hash or binary search instead.

Are you thinking that to find each function the executable code would
carry out the hash or binary search at run time (if optimisation didn't
remove the need for it)?

My guess is that Python works that way: each name referred to in a
method is subjected to lookup in a series of tables (in something called
Method Resolution Order, MRO) starting with the object and ascending to
each class in the MRO in turn until a matching name is found. But that's
slow.

In compiled code, carrying out a hash lookup or a binary search just to
find which function to call would be faster than Python but still too slow.

>
>> My intention was for the tag to be the address of the dispatch table
>> so that functions (as long as they were at known offsets) could be
>> accessed quickly but I don't think you liked that.
>
> 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.

>
> Then again, if you don't repeat C++ and Java error confusing class-wide
> and specific types, you would drastically reduce cases when dispatch
> ever happens. Most of the code deals with statically known specific
> types, ergo, no dispatch (or as some call it, "static dispatch").

I'm not sure I understand that but if you think C++ and Java got it
wrong do you think Ada got it right and what did it do differently?

>
> Segmented dispatching tables is IMO a bigger problem unless you rebuild
> affected dispatching each time you load a library or dynamically create
> a new type etc.
>

I presume that means when a large dispatch table reaches the limits of
its allocated memory and has to be split.

--
James Harris

On 03/09/2021 14:59, Bart wrote:
> On 03/09/2021 13:27, James Harris wrote:

....

> OK, the example was clearly a simple one to illustrate some aspects of
> how OOP works. But I see such examples using shapes all the time and
> find them somewhat annoying.

I recently had to take a first look at how I'd want a GUI to work. My
answer was basically sentient widgets which knew how to operate on data
and how to draw themselves. But the drawing would be by graphics
primitives which were provided by the surfaces on which the widgets
wanted to appear. Without having implemented any of this, yet, that
seems to me to be the best approach.

>
> It gives the impression that OOP can magically solve all the problems
> that come up in actual applications, but the reality is always a lot
> more complicated.

OOP has lots wrong with it - including multiple incompatible ways of
realising it.

ADTs, by contrast, are great. Each type comes with its own functions.

Don't throw the ADTs out with the OOP!

>
> I'm rather sceptical about what OOP can do, and I have firm views on how
> far a language should get involved in matters that should be the concern
> of an application.
>
> I also think that, if you really want to use OOP seriously, then you're
> quite liable to just end up reinventing C++, as you meet the same
> obstacles.)

I don't know much about C++ but ending up with similar solutions is
unlikely as its design goals are different.
>
>
>  What I take from it is that, however
>> it's done, the address of the drawing function (the ptr in the above
>> table) would need to be found from a key of three parameters
>>
>>    (shape type, surface type, function name)
>>
>> whereas single dispatch would find a function based on two parameters
>> such as
>>
>>    (shape type, function name)
>>
>> Is that correct?
>
> The shape should describe the shape itself and nothing else. If you want
> to plot it, then extra information is needed:
>
>    p.plot(surface_type)
>
> With perhaps that parameter being optional when there is a sensible
> default. So here there is single dispatch based on shape type.
>
> Anything else would be difficult to get your head around. If there are M
> shape types and N surface types, then you've got MxN methods to write,

Indeed, that's exactly the issue. Better to have the M shapes (or
widgets) use a set of drawing primitives, and have those provided by the
N surface types, IMO.

> but where are you going to write them? Functions are written one after
> the other, not in a table!
>
> You might consider introducing overloaded functions, so the plot()
> method for Rectangle is split into one each for PDF and SVG. Feature creep.
>
> (My approach as I used was single dispatch - a simple switch - using
> common code to reduce complex objects to basic edges, and then using
> single dispatch on the 'surface' when drawing those edges.)
>

Why not say that each surface has to provide a set of primitives that
other programs can use to draw on an instance of that type of surface?

--
James Harris

On 2021-09-03 16:59, James Harris wrote:

> Why not say that each surface has to provide a set of primitives that
> other programs can use to draw on an instance of that type of surface?

Because that set is open ended. OOP allows you

1. adding new primitives (new shapes)

2. using primitives with new surfaces (inheritance)

All counter proposals are static and do not scale in practice, which is
why OOP is used so widely in large projects regardless any difficulties.
There is simple no other way to do it, economically, there is no other way.

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

On 2021-09-03 16:40, James Harris wrote:
> On 03/09/2021 14:39, Dmitry A. Kazakov wrote:
>> On 2021-09-03 14:27, James Harris wrote:
>>> On 30/08/2021 22:13, Dmitry A. Kazakov wrote:
>>>> On 2021-08-30 22:25, James Harris wrote:
>>>>> On 30/08/2021 12:36, Dmitry A. Kazakov wrote:
>>>
>>> ...
>>>
>>>>>> In the most general case a dispatching table belongs to the
>>>>>> method, not to the type. The tag would denote an N-th coordinate
>>>>>> (plane) of the multidimensional index in the table.
>>>>>
>>>>> That sounds weird. If the dispatch table belongs to the method what
>>>>> would it be indexed by?
>>>>
>>>> By the type, of course. It is pretty straightforward. Consider
>>>>
>>>>     Surface       Shape
>>>>       /  \         /  \
>>>>     PDF  SVG  Ellipse  Rectangle
>>>>
>>>>     Draw      | PDF | SVG |
>>>>     ----------+-----+-----+
>>>>     Ellipse   | ptr | ptr |
>>>>     ----------+-----+-----+
>>>>     Rectangle | ptr | ptr |
>>>>     ----------+-----+-----+
>>>
>>> That solution looks as though the shapes would have to know how to
>>> draw themselves on different surfaces. As such I doubt it would scale
>>> well as new shapes and new types of surface were added. But maybe
>>> it's purely illustrative of multiple dispatch. What I take from it is
>>> that, however it's done, the address of the drawing function (the ptr
>>> in the above table) would need to be found from a key of three
>>> parameters
>>>
>>>    (shape type, surface type, function name)
>>>
>>> whereas single dispatch would find a function based on two parameters
>>> such as
>>>
>>>    (shape type, function name)
>>>
>>> Is that correct?
>>
>> Yes, and the surface parameter is then class-wide, i.e. each function
>> must have to deal with any shape (any instance from the class =
>> class-wide).
>
> OK. I am now trying to understand what you mean by 'class wide'.

Class-wide = anything from the members of the class.

> Are you
> saying that each drawing function would have to be passed the target
> surface as a parameter - and that makes surface 'class wide'?

Not only passed, it must accept any surface of any surface type. In
particular it means that it must know the type tag.

> In practice, I'd imagine it's best for 'surfaces' to know how to draw on
> themselves and they would export drawing primitives (such as point,
> line, curve, rectangle, ellipse etc) which routines can call.

I commented on that in another post.

>>>>> When you talk about a tag do you mean something that might, if it
>>>>> cannot be optimised any better, result in a series of three or even
>>>>> more lookups executed at run time before the required method is found?
>>>>
>>>> Yes. You need some unique type identifier, short enough to fit in a
>>>> register.
>>>
>>> If the tag is the unique identifier you mention how would the
>>> compiled code get from the tag to the correct routine?
>>
>> Via the dispatching table indexed by the tag. Tag could not be a dense
>> index, true, so you would use a hash or binary search instead.
>
> Are you thinking that to find each function the executable code would
> carry out the hash or binary search at run time (if optimisation didn't
> remove the need for it)?

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

Tag -> 1st Foo's parameter Hash = I1
Tag -> 2nd Foo's parameter Hash = I2
..
Tag -> Nth Foo's parameter Hash = IN

Foo_Table (I1, I2, ... IN) --> Target pointer

There exist multi-dimensional hash techniques which would allow you to
do it in less steps. I do not know how effective they are.

>> 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.

Faster than anything the user would have to write otherwise, in order to
emulate dispatch.

Then performance is never a big concern. Safety is. User emulations of
dispatch would be nested if-statements, which are not only significantly
slower O(n), but inherently error-prone and unmaintainable.

>> Then again, if you don't repeat C++ and Java error confusing
>> class-wide and specific types, you would drastically reduce cases when
>> dispatch ever happens. Most of the code deals with statically known
>> specific types, ergo, no dispatch (or as some call it, "static
>> dispatch").
>
> I'm not sure I understand that but if you think C++ and Java got it
> wrong do you think Ada got it right and what did it do differently?

If foo and baz are virtual functions of T then

void foo (T& x)
{
x.baz (); -- Dispatches
}

In Ada

procedure Foo (X : T) is
begin
X.Baz; -- Does not dispatch, the type is established to be T
end Foo;

>> Segmented dispatching tables is IMO a bigger problem unless you
>> rebuild affected dispatching each time you load a library or
>> dynamically create a new type etc.
>
> I presume that means when a large dispatch table reaches the limits of
> its allocated memory and has to be split.

Not large, but consisting of several parts, so that you must linearly
search through all of them.

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

On 03/09/2021 16:28, Dmitry A. Kazakov wrote:
> On 2021-09-03 16:59, James Harris wrote:
>
>> Why not say that each surface has to provide a set of primitives that
>> other programs can use to draw on an instance of that type of surface?
>
> Because that set is open ended. OOP allows you
>
> 1. adding new primitives (new shapes)
>
> 2. using primitives with new surfaces (inheritance)
>
> All counter proposals are static and do not scale in practice, which is
> why OOP is used so widely in large projects regardless any difficulties.
> There is simple no other way to do it, economically, there is no other way.
>

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!

The rights and wrongs of the approach are OT so all I'll say is that M*N
does not scale and that new shapes can be constructed from primitives.

Unless I am missing something the cartesian M*N would be costly and so
even economically, as you mention, I cannot agree that there is no other
way.

--
James Harris

On 2021-09-03 18:43, James Harris wrote:
> On 03/09/2021 16:28, Dmitry A. Kazakov wrote:
>> On 2021-09-03 16:59, James Harris wrote:
>>
>>> Why not say that each surface has to provide a set of primitives that
>>> other programs can use to draw on an instance of that type of surface?
>>
>> Because that set is open ended. OOP allows you
>>
>> 1. adding new primitives (new shapes)
>>
>> 2. using primitives with new surfaces (inheritance)
>>
>> All counter proposals are static and do not scale in practice, which
>> is why OOP is used so widely in large projects regardless any
>> difficulties. There is simple no other way to do it, economically,
>> there is no other way.
>>
>
> 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.

> The rights and wrongs of the approach are OT so all I'll say is that M*N
> does not scale and that new shapes can be constructed from primitives.

You did not thought it through. A set of primitives supported by all
shapes is already a class. This is exactly what a class of shapes is.
Any client of the class expects to find an implementation of any
primitive in any surface.

Remove the class, you will need to write a new client for each surface.

> Unless I am missing something the cartesian M*N would be costly and so
> even economically, as you mention,

And its existence is a fact of life. Shapes exist, surfaces exist,
drawing exist.

> I cannot agree that there is no other way.

Show the other way to implement and use M*N operations safely.

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

On 03/09/2021 18:27, Dmitry A. Kazakov wrote:
> On 2021-09-03 18:43, James Harris wrote:

>
>> Unless I am missing something the cartesian M*N would be costly and so
>> even economically, as you mention,
>
> And its existence is a fact of life. Shapes exist, surfaces exist,
> drawing exist.
>
>> I cannot agree that there is no other way.
>
> Show the other way to implement and use M*N operations safely.

Say you have an enum type listing M different shapes, and another
listing N different surfaces:

* Create a 2D MxN array H of function pointers

* Populate the table (see below)

* To plot any shape S, call the function H[shape_tag, surface_type]

To populate the table (this is what I can do in my language; probably
it's not possible in Ada or others, it might need external
code-generation, or auxiliary, manually-created tables of available
combinations):

* Write the functions for the combinations of Shape and Surface that are
supported; name the functions according to some agreed format. (These
might be methods; that is just a detail)

* Have an initialisation routine that scans all functions in the program
looking for those that implement the plotting (it will look at the name)

* For each such function, extract the shape X and surface Y it
implements, from the name. Fill in H[X,Y] with a reference to the function

* For all table entries not yet populated, fill in a reference to an
error-handler or default-handling function. 'nil' is not recommended!

On 2021-09-03 19:44, Bart wrote:
> On 03/09/2021 18:27, Dmitry A. Kazakov wrote:
>> On 2021-09-03 18:43, James Harris wrote:
>
>>
>>> Unless I am missing something the cartesian M*N would be costly and
>>> so even economically, as you mention,
>>
>> And its existence is a fact of life. Shapes exist, surfaces exist,
>> drawing exist.
>>
>>> I cannot agree that there is no other way.
>>
>> Show the other way to implement and use M*N operations safely.
>
> Say you have an enum type listing M different shapes, and another
> listing N different surfaces:
>
> * Create a 2D MxN array H of function pointers

Failed. The requirement included different teams of developers and
different times rows and columns (types) added.

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

On 03/09/2021 19:01, Dmitry A. Kazakov wrote:
> On 2021-09-03 19:44, Bart wrote:
>> On 03/09/2021 18:27, Dmitry A. Kazakov wrote:
>>> On 2021-09-03 18:43, James Harris wrote:
>>
>>>
>>>> Unless I am missing something the cartesian M*N would be costly and
>>>> so even economically, as you mention,
>>>
>>> And its existence is a fact of life. Shapes exist, surfaces exist,
>>> drawing exist.
>>>
>>>> I cannot agree that there is no other way.
>>>
>>> Show the other way to implement and use M*N operations safely.
>>
>> Say you have an enum type listing M different shapes, and another
>> listing N different surfaces:
>>
>> * Create a 2D MxN array H of function pointers
>
> Failed. The requirement included different teams of developers and
> different times rows and columns (types) added.
>

How is that relevant? Presumably all the necessary information (method
definitions or their interfaces) will be visible to the (presumably AOT)
compiler when the application is built?

Then who cares who wrote it or when.

Anyway who are you to say how my application will be organised.