Let's talk about multiple inheritance and interfaces.

[Christopher Pisz]

I am having one of those "intellectual discussions" with a coworker whom
is making some bold sweeping claims about C++ and C#, which I have to
disagree with. It's lighthearted and for fun. I wonder what others say
on the topic.

He has put forth the following

Premise: Multiple inheritance is universally accepted as bad
Conclusion: Although the compiler allows you to, you should never use
multiple inheritance in C++

Premise: C# enforces an interface to contain no functionality or data in C#
Premise: The problems with multiple inheritance can be eliminated
because of the former premise.
Conclusion: Inheriting from an interface in C# "doesn't count" as
multiple inheritance and you _should_ do it

I have countered that "just because the compiler doesn't enforce"
something doesn't mean I "cannot" or "should not" do it in C++

Premise: I can create an interface in C++ the same as you can in C#
Premise: I can inherit from interfaces in the same manner as you can in C#
Conclusion: If you can do it I can too and, in fact, I should do it.

He disagrees with my final conclusion and I cannot for the life of me
fathom why.

Am I missing something? Do we need to explore a premise further?
What are your thoughts?






--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---

[4ndre4]

On 27/01/2016 20:16, Christopher Pisz wrote:

> I am having one of those "intellectual discussions" [...]

Rather than discussing in abstract terms, it would be nice to examine a
real case, where C# interfaces prove to be a better solution than C++
abstract classes, or vice versa. The only problem with mi that comes to
my mind is the classic diamond problem.

--
4ndre4
"The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offense." (E. Dijkstra)

[Daniel]

On Wednesday, January 27, 2016 at 3:16:36 PM UTC-5, Christopher Pisz wrote:
>
> Premise: Multiple inheritance is universally accepted as bad
> Conclusion: Although the compiler allows you to, you should never use
> multiple inheritance in C++
>
> Premise: C# enforces an interface to contain no functionality or data in C#
> Premise: The problems with multiple inheritance can be eliminated
> because of the former premise.
> Conclusion: Inheriting from an interface in C# "doesn't count" as
> multiple inheritance and you _should_ do it
>

I think the experience of Java and C# is that multiple inheritance of interfaces is very useful, and that multiple inheritance of implementations is not missed, so may as well leave the latter out and avoid the complications.

As

class I
{
public:
virtual void f() = 0;
}

class A : public B, public virtual I

is directly analogous to inheriting from an interface, I don't see how a Java or C# guy could object.

Still, it seems public virtual inheritance is rarely used in C++ code, as compared to interfaces in Java and C#. Perhaps it is because C++ has const, which effectively gives a class two "interfaces", roughly speaking, a mutable and an immutable one. In Java and C#, these would be supported as interfaces.

Daniel

[Mr Flibble]

I think it is fine to use MI as long as only one derivation is public
with any others being private which means "implemented-in-terms-of"
relationship rather than "is-a" sausages.

/Flibble

[Scott Lurndal]

Christopher Pisz <nos...@notanaddress.com> writes:
>I am having one of those "intellectual discussions" with a coworker whom
>is making some bold sweeping claims about C++ and C#, which I have to
>disagree with. It's lighthearted and for fun. I wonder what others say
>on the topic.
>
>He has put forth the following
>
>Premise: Multiple inheritance is universally accepted as bad
>Conclusion: Although the compiler allows you to, you should never use
>multiple inheritance in C++
>
>Premise: C# enforces an interface to contain no functionality or data in C#
>Premise: The problems with multiple inheritance can be eliminated
>because of the former premise.
>Conclusion: Inheriting from an interface in C# "doesn't count" as
>multiple inheritance and you _should_ do it
>
>I have countered that "just because the compiler doesn't enforce"
>something doesn't mean I "cannot" or "should not" do it in C++
>
>Premise: I can create an interface in C++ the same as you can in C#
>Premise: I can inherit from interfaces in the same manner as you can in C#
>Conclusion: If you can do it I can too and, in fact, I should do it.
>
>He disagrees with my final conclusion and I cannot for the life of me
>fathom why.
>
>Am I missing something? Do we need to explore a premise further?
>What are your thoughts?

It's all a waste of time. Write programs that solve the stated
problem and don't worry about what someone else says is the right
or wrong way to do things.

There's nothing fundamentally wrong with multiple inheritance. Like
any language feature, it can be misused, but that shouldn't preclude
its use.

Note that an abstract class (pure virtual) is functionally indistinguishable from a
Java or C# interface.

[Öö Tiib]

On Wednesday, 27 January 2016 22:16:36 UTC+2, Christopher Pisz wrote:
> I am having one of those "intellectual discussions" with a coworker whom
> is making some bold sweeping claims about C++ and C#, which I have to
> disagree with. It's lighthearted and for fun. I wonder what others say
> on the topic.
>
> He has put forth the following
>
> Premise: Multiple inheritance is universally accepted as bad
> Conclusion: Although the compiler allows you to, you should never use
> multiple inheritance in C++
>
> Premise: C# enforces an interface to contain no functionality or data in C#
> Premise: The problems with multiple inheritance can be eliminated
> because of the former premise.
> Conclusion: Inheriting from an interface in C# "doesn't count" as
> multiple inheritance and you _should_ do it
>
> I have countered that "just because the compiler doesn't enforce"
> something doesn't mean I "cannot" or "should not" do it in C++
>
> Premise: I can create an interface in C++ the same as you can in C#
> Premise: I can inherit from interfaces in the same manner as you can in C#
> Conclusion: If you can do it I can too and, in fact, I should do it.
>
> He disagrees with my final conclusion and I cannot for the life of me
> fathom why.
>
> Am I missing something? Do we need to explore a premise further?
> What are your thoughts?

If a feature is simplifying writing working software then we should
use it.

Run-time dynamic polymorphism in general and multiple inheritance in
particular are complex features and so only sometimes simplify
writing software. KISS, DRY, YAGNI

There are number of other popular programming languages that have
multiple inheritance (for example Python, Common Lisp and Scala).

C# does not matter. When we program in some other language then it
is irrelevant what one can or can not do in C#.

[Christopher Pisz]

On 1/27/2016 2:40 PM, 4ndre4 wrote:
> On 27/01/2016 20:16, Christopher Pisz wrote:
>
>> I am having one of those "intellectual discussions" [...]
>
> Rather than discussing in abstract terms, it would be nice to examine a
> real case, where C# interfaces prove to be a better solution than C++
> abstract classes, or vice versa. The only problem with mi that comes to
> my mind is the classic diamond problem.
>

I agree 100% the diamond problem is a problem, but I can just as easily
adapt the "An interface does not contain functionality or data" and then
the diamond problem is no longer a problem, right?

if my C++ "interface" is an abstract class (since we don't have a
interface keyword", which contains 100% pure virtuals, then I don't
think there is a problem, since D, in the examples, would be forced to
implement the the method. But it would be up to the developers to
enforce the rules that 'thou shalt only multiple inherit from abstract
classes with 100% pure virtual methods', which would be difficult, i
agree, to enforce. Doable none the less.

[Cholo Lennon]

On 01/27/2016 05:16 PM, Christopher Pisz wrote:
> I am having one of those "intellectual discussions" with a coworker whom
> is making some bold sweeping claims about C++ and C#, which I have to
> disagree with. It's lighthearted and for fun. I wonder what others say
> on the topic.
>
> He has put forth the following
>
> Premise: Multiple inheritance is universally accepted as bad
> Conclusion: Although the compiler allows you to, you should never use
> multiple inheritance in C++
>
> Premise: C# enforces an interface to contain no functionality or data in C#
> Premise: The problems with multiple inheritance can be eliminated
> because of the former premise.
> Conclusion: Inheriting from an interface in C# "doesn't count" as
> multiple inheritance and you _should_ do it
>
> I have countered that "just because the compiler doesn't enforce"
> something doesn't mean I "cannot" or "should not" do it in C++
>
> Premise: I can create an interface in C++ the same as you can in C#
> Premise: I can inherit from interfaces in the same manner as you can in C#
> Conclusion: If you can do it I can too and, in fact, I should do it.
>
> He disagrees with my final conclusion and I cannot for the life of me
> fathom why.
>
> Am I missing something? Do we need to explore a premise further?
> What are your thoughts?
>

Well, in its last version (8), Java added default implementation for
interface methods (aka default methods). Why? IMO, it's because in a lot
of situations you need a default behavior (as simple as an empty code
for example), but with the mentioned restriction to multiple inheritance
of classes , that could not be done. C++ doesn't have that problem (but
C# still has it). Also, MI + abstract classes in C++ are more powerful
than interfaces with default methods in Java ;-)


Regards


--
Cholo Lennon
Bs.As.
ARG

[Jerry Stuckle]

On 1/27/2016 3:16 PM, Christopher Pisz wrote:
> I am having one of those "intellectual discussions" with a coworker whom
> is making some bold sweeping claims about C++ and C#, which I have to
> disagree with. It's lighthearted and for fun. I wonder what others say
> on the topic.
>
> He has put forth the following
>
> Premise: Multiple inheritance is universally accepted as bad

Premise: Any premise that says something is "universally accepted" is bad.

> Conclusion: Although the compiler allows you to, you should never use
> multiple inheritance in C++
>

Premise: Statements which use "never" are never correct (including this
one).

> Premise: C# enforces an interface to contain no functionality or data in C#
> Premise: The problems with multiple inheritance can be eliminated
> because of the former premise.
> Conclusion: Inheriting from an interface in C# "doesn't count" as
> multiple inheritance and you _should_ do it
>

An interface in c# is nothing more than a an abstract class with no data
members in C++.

> I have countered that "just because the compiler doesn't enforce"
> something doesn't mean I "cannot" or "should not" do it in C++
>
> Premise: I can create an interface in C++ the same as you can in C#
> Premise: I can inherit from interfaces in the same manner as you can in C#
> Conclusion: If you can do it I can too and, in fact, I should do it.
>

I agree completely.

> He disagrees with my final conclusion and I cannot for the life of me
> fathom why.
>
> Am I missing something? Do we need to explore a premise further?
> What are your thoughts?
>

I will, however, say I have see multiple inheritance misused more than
used correctly. It's not as bad when the base class has no data
members, effectively acting as a C# interface. Having only pure virtual
functions makes it even better.

But there are times when it can be useful, and I have occasionally used
it in the past. But not often.

--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================

[Vir Campestris]

On 27/01/2016 20:16, Christopher Pisz wrote:

> Premise: Multiple inheritance is universally accepted as bad
> Conclusion: Although the compiler allows you to, you should never use
> multiple inheritance in C++

I've used it exactly once.

There was a feature in the spec which described data of three types.
That's OK, except there were consumers which could take types a or b,
and those that could take b or c (and some that could take any of
them!). We found it easiest to make classes for a, b, and c, and to make
an ab class deriving from a and b, and a bc class deriving from b & c.

The spec BTW was an open standard. We always wondered what they smoked
in the comi9ttee meetings!

Andy

[Mr Flibble]

On 27/01/2016 21:05, Scott Lurndal wrote:
>
> Note that an abstract class (pure virtual) is functionally indistinguishable from a
> Java or C# interface.

In C++ "abstract base class" doesn't mean "interface" it means a class
with *at least* one pure virtual function.

There is nothing wrong with using the term "interface" when talking
about C++ code *if* one is referring to a class which:

* contains pure virtual functions with no implementation;
* contains trivial inline helper functions which call the pure virtual
functions;
* does not contain a class invariant.

I like to use the term "mixin" for the other type of abstract base class
which is basically used to implement the template method design pattern
sausages.

/Flibble

[Alf P. Steinbach]

On 1/27/2016 9:16 PM, Christopher Pisz wrote:
> Conclusion: Although the compiler allows you to, you should never use
> multiple inheritance in C++

I.e. don't use mixin classes.

That would be seriously dumb.

E.g.,

class Foo
: Non_copyable, // Common with Boost'ed code.
, Relops_from_compare< Foo > // Original case for BN trick.
, Small_objects_alloc< Foo > // Smth. like that from Loki.
{
public:
friend
auto compare( In_<Foo> A, In_<Foo> B )
-> int
{ ... }
};


Cheers & hth.,

- Alf

PS: Since I see no-one has so far mentioned it, to emulate Java/C#
inheritance in C++, so that an inherited class can provide an
implementation of an interface, one must use virtual inheritance.

[Mr Flibble]

Why would you want to emulate Java/C# inheritance in C++? If you are
using C++ then use C++.

/Flibble

[4ndre4]

On 27/01/2016 21:14, Christopher Pisz wrote:

> I agree 100% the diamond problem is a problem, but I can just as easily
> adapt the "An interface does not contain functionality or data" and then
> the diamond problem is no longer a problem, right?

Actually, to avoid the diamond problem, you can just resort to virtual
inheritance. You do not necessarily need to make the base class at the
top of the diamond the equivalent of a C# interface.

You can have this:

#include <iostream>

class Storable {
public:
virtual void read() {
std::cout << "storable reading" << std::endl;
};
virtual void write() {
std::cout << "storable writing" << std::endl;
};
};

class Receiver : public virtual Storable {
public:
void read() {
std::cout << "receiver reading" << std::endl;
}
};

class Transmitter : public virtual Storable {
public:
void write() {
std::cout << "transmitter writing" << std::endl;
}
};

class Radio: public Receiver, Transmitter {
public:
void read() {
std::cout << "radio reading" << std::endl;
}
void write() {
std::cout << "radio writing" << std::endl;
}
};

int main()
{
Storable* p = new Radio();
p->read();
p->write();

p = new Receiver();
p->read();
p->write();

p = new Transmitter();
p->read();
p->write();

return 0;
}


The output is, as expected:

radio reading
radio writing
receiver reading
storable writing
storable reading
transmitter writing

Of course, if you remove "virtual" from the intermediate base classes,
you'll get the diamond ambiguity back, with the compiler stopping with a
fatal error.

[Marcel Mueller]

On 27.01.16 21.16, Christopher Pisz wrote:
> Premise: Multiple inheritance is universally accepted as bad

Wrong.

There are problems that are really hard to solve without multiple
inheritance. At least it breaks the "don't repeat yourself" rule.

Example:
Think of an entity data model. Each entity has a immutable, inherently
thread-safe representation and a mutable representation. Of course, any
code that works with the read only (maybe cached) entities is supposed
to work also with local mutable instances rather than the shared
immutable ones. It is up to the caching framework to deliver either
type. But you can always enforce a mutable copy, if you intend to make
changes.
It is straight forward to solve this by inheritance. The mutable classes
inherit from the immutable ones add some further methods.

Additionally there are strong entities (with a strong key), weak
entities (i.e. children of strong entities with sub keys) and simple
entities without any key. This is also straight forward to be serviced
with inheritance. Whatever you can do with a simple entity can be done
with weak or strong entities as well.

Now you have multiple inheritance.
A strong mutable entity inherits from the simple entity as well as from
the strong immutable entity. You need both implicit conversions to make
all code work.

I had to implement something like that in C# and it really wasn't fun
because of the lack of multiple inheritance.

Another example:
Think of a logger API. You may have a FileLogger class and e.g. a
DailyFileLogger class that inherits from the first and added
functionality for logfile rotation.
For performance reasons there are multi-tasking safe implementations
that synchronize write access to the file (even over the network) and
single task implementations that simply keep the file open in exclusive
write mode. Any application that can deal with the local implementation
is supposed to work with the synchronized classes as well.
Again you have multiple inheritance.

> Conclusion: Although the compiler allows you to, you should never use
> multiple inheritance in C++

Well, if you do not know what you are doing then you should avoid
multiple inheritance. Otherwise it might be very useful in some cases.
Of course, like any other pattern one should not abuse it.

It is like multiple dispatch. If you really need it, code becomes really
ugly if the language (like C++) does not support it.


Marcel

[Rosario19]

On Wed, 27 Jan 2016 14:16:23 -0600, Christopher Pisz wrote:

>I am having one of those "intellectual discussions" with a coworker whom
>is making some bold sweeping claims about C++ and C#, which I have to
>disagree with. It's lighthearted and for fun. I wonder what others say
>on the topic.

i never had find a problem where it is need "virtual" until now

[Zaphod Beeblebrox]

On Thursday, 28 January 2016 02:36:39 UTC, Marcel Mueller wrote:

> There are problems that are really hard to solve without multiple
> inheritance.

I am suspecting that for the problems you are presenting, composition is a better choice than inheritance/MI. Maybe I got it wrong. Can you offer some code examples?

[Alf P. Steinbach]

Yeah, I mostly agree.

Still there's a school of thought that one should always inherit
virtually from an interface (pure abstract class). The Java-like
“inherit in an implementation” is one possible reason, because, as an
example, it comes into play when you have an interface A, an
implementation of A called say A_impl, plus an interface that extends A,
say B, and you want to provide the extended interface B with the A_impl
implementation of the A part. And another possible reason is to ensure
that direct casting up to some given interface is unambiguous, e.g. for
catching an exception as reference to that interface.

Still, there are workarounds for those issues, I think that doing
exception discrimination via interfaces is complexity for no gain, and
while virtual inheritance of an interface doesn't confront you with the
special construction order for virtual base classes (which sort of
stinks) there is a run time cost of extra indirection (which itches).


Cheers!,

- Alf

Disclaimer: no coffee yet, just out of bed.

[JiiPee]

beautifully written code. :) easy to read...

[Zaphod Beeblebrox]

On Thursday, 28 January 2016 11:38:58 UTC, JiiPee wrote:

[...]

> beautifully written code. :) easy to read...

A code that doesn't do anything is always easy to read :D

[Scott Lurndal]

Vir Campestris <vir.cam...@invalid.invalid> writes:
>On 27/01/2016 20:16, Christopher Pisz wrote:
>> Premise: Multiple inheritance is universally accepted as bad
>> Conclusion: Although the compiler allows you to, you should never use
>> multiple inheritance in C++
>
>I've used it exactly once.
>

I use it often, for example:

/**
* Reset block
*/
class Reset: public Device,
public MemoryAccessors,
GpioPinCb,
public Thread
{
};

MemoryAccessors and GpioPinCb are both pure virtual classes (interfaces).
Thread and Device are base classes.

A pointer to the instance as 'MemoryAccessors *' is kept in the
object that manages the physical address space, and a pointer to
the instance as 'GpioPinCb *' is kept in the GPIO device object
instance. A pointer to the instance as 'Device *' is kept in the
master device vector, and a pointer to the instance as 'Thread *'
is kept by the thread manager singleton.

[Vir Campestris]

Have you never seen the Obfuscated C contest?

Andy

[4ndre4]

On 28/01/2016 21:17, Vir Campestris wrote:

[...]

> Have you never seen the Obfuscated C contest?

The difference is that in the Obfuscated C contest, the code does
something in an incomprehensible way. My code does not really do
anything :)

[Öö Tiib]

On Friday, 29 January 2016 00:07:17 UTC+2, 4ndre4 wrote:
> On 28/01/2016 21:17, Vir Campestris wrote:
>
> [...]
> > Have you never seen the Obfuscated C contest?
>
> The difference is that in the Obfuscated C contest, the code does
> something in an incomprehensible way. My code does not really do
> anything :)

Oh it does. It leaks 3 stateless objects.

[Zaphod Beeblebrox]

On Thursday, 28 January 2016 22:53:55 UTC, Öö Tiib wrote:
[...]

> Oh it does. It leaks 3 stateless objects.

What do you mean?

[Öö Tiib]

What word don't you understand? "3", "objects", "stateless" "leaks"?

[4ndre4]

On 30/01/2016 15:10, Öö Tiib wrote:

[...

> What word don't you understand? "3", "objects", "stateless" "leaks"?

I think it would be much more productive (for everyone) if, rather than
using a polemic tone in each message, people explained what they mean
pacifically. If you mean that my code "leaks" 3 objects because it does
not deallocate them, then nobody really cares. It's just an example to
show how virtual inheritance works.

[4ndre4]

On 30/01/2016 18:45, Stefan Ram wrote:

[...]
> We do care about proper lifetime control in this newsgroup

Oh please, don't be ridiculous. You care about polemicising about futile
details all the time in this ng. That example was not about the usage of
pointers, it was about virtual inheritance. Last reply from me.

[Paavo Helde]

On 30.01.2016 19:52, 4ndre4 wrote:
> On 30/01/2016 15:10, Öö Tiib wrote:
>
> [...
>> What word don't you understand? "3", "objects", "stateless" "leaks"?
>
> I think it would be much more productive (for everyone) if, rather than
> using a polemic tone in each message, people explained what they mean
> pacifically. If you mean that my code "leaks" 3 objects because it does
> not deallocate them, then nobody really cares. It's just an example to
> show how virtual inheritance works.

Yes, this is an example what some newbie may find in a google search and
reuse in his project, claiming that using raw pointers is OK because the
gurus in c.l.c++ do it as well.

But you are right, it was not important for the actually discussed
topic, so it should not bother you if Öö Tiib and Zaphod Beeblebrox want
to discuss this in more detail or not.

Cheers
Paavo

[Öö Tiib]

On Saturday, 30 January 2016 19:52:29 UTC+2, 4ndre4 wrote:
> On 30/01/2016 15:10, Öö Tiib wrote:
>
> [...
> > What word don't you understand? "3", "objects", "stateless" "leaks"?
>
> I think it would be much more productive (for everyone) if, rather than
> using a polemic tone in each message, people explained what they mean
> pacifically.

Sorry for my tone if it offended anyone. It was worth
mentioning, not worth big polemics.

RAII ("Resource Acquisition Is Initialization") is one of most basic
idioms in C++ programming language. It is worth learning before class
inheritance and polymorphism. C++ code that does not follow RAII can
still be correct but very often leaks resources or is not exception-safe.
Same is perhaps with some other programming languages like Ada and D.
I saw your code as a good example how such code leaks resources.

> If you mean that my code "leaks" 3 objects because it does
> not deallocate them, then nobody really cares. It's just an example to
> show how virtual inheritance works.

When basic resource management and exception safety are missing from
code then it is unusual for me. I see something like that in code of my
coworkers very rarely, even if it was only meant as test or demo. So
I found it worth mentioning as unusual defect.

[Juha Nieminen]

Christopher Pisz <nos...@notanaddress.com> wrote:
> Premise: Multiple inheritance is universally accepted as bad

When asked *why* multiple inheritance is bad, one, and only one example is
always and ever given: Diamond inheritance.

So why not say that diamond inheritance is bad, rather than multiple
inheritance? Why is MI blamed for a different pattern?

There is absolutely nothing wrong with multiple inheritance. Not from
a practice point of view nor from a design point of view.

From a design point of view inheritance creates an "is-a" relationship.
Multiple inheritance simply adds additional "is-a" relationships
(which I like to call "and-a").

For example:

class Button: public Widget, public ReferenceCountable

means "Button is-a Widget and-a ReferenceCountable (object)"

The above example also demonstrates why multiple inheritance is useful.
Ostensibly both Widget and ReferenceCountable have members and methods
of their own, and their usage in this situation is sensible.

"Interfaces" are nothing more than a crippled form of multiple inheritance.
Saying otherwise is silly. The design relationship is exactly the same
(your class will have an "is-a" relationship with an interface in the
exact same way as with an actual class. There is no practical difference.)

The crippling of interfaces simply causes needless code repetition in
many cases (because the same methods need to be implemented again and
again; moreover, many of the languages offering interfaces do not offer
any way of avoiding this code repetition.) Code repetition is one of the
worst designs in programming.

Why not allow method implementations and members in interfaces? There is
no technical nor designwise reason not to allow that. Simply disallow
diamond inheritance if that's so scary.

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Scott Lurndal]

r...@zedat.fu-berlin.de (Stefan Ram) writes:

>4ndre4 <4nd...@4ndre4.com.invalid> writes:
>>I think it would be much more productive (for everyone) if, rather than
>>using a polemic tone in each message, people explained what they mean
>>pacifically. If you mean that my code "leaks" 3 objects because it does
>>not deallocate them, then nobody really cares. It's just an example to
>>show how virtual inheritance works.
>

> We do care about proper lifetime control in this newsgroup and
> usually use smart pointers instead of raw pointers, even if it

Speak for yourself, kemosabe.

[Öö Tiib]

Was "kemosabe" mean here as "trusty scout" or "faithful friend"?

[Scott Lurndal]

Neither, in this case. It's american slang from the era
of the lone ranger shorts in the theaters.

[Jerry Stuckle]

Actually, it comes from even before that - the first radio broadcast
when the Lone Ranger legend began. Except it was the Lone Ranger who
call Tonto "Kemo sabe", not the other way around.

I've still got a 78 rpm of the original broadcast.


--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================

[Vir Campestris]

On 01/02/2016 20:07, Jerry Stuckle wrote:
> Actually, it comes from even before that - the first radio broadcast
> when the Lone Ranger legend began. Except it was the Lone Ranger who
> call Tonto "Kemo sabe", not the other way around.

Who are you calling tonto?

<http://www.spanishdict.com/translate/tonto>

(I didn't know that when I was a kid...)

Andy

[Jerry Stuckle]

Tonto was an American Indian name (I forget which tribe), not Spanish.
Tonto was the name of the Lone Ranger's partner.

[Vir Campestris]

On 02/02/2016 00:56, Jerry Stuckle wrote:
> On 2/1/2016 4:20 PM, Vir Campestris wrote:
>> On 01/02/2016 20:07, Jerry Stuckle wrote:
>>> Actually, it comes from even before that - the first radio broadcast
>>> when the Lone Ranger legend began. Except it was the Lone Ranger who
>>> call Tonto "Kemo sabe", not the other way around.
>>
>> Who are you calling tonto?
>>
>> <http://www.spanishdict.com/translate/tonto>
>>
>> (I didn't know that when I was a kid...)
>>
>> Andy
>
> Tonto was an American Indian name (I forget which tribe), not Spanish.
> Tonto was the name of the Lone Ranger's partner.
>

I thought you might be on to something when I found this

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

Then I read on...

"The Tonto Apache (Dilzhę́’é, also Dilzhe'e, Dilzhe’eh Apache) is one of
the groups of Western Apache people. The term is also used for their
dialect, one of the three dialects of the Western Apache language (a
Southern Athabaskan language). The Chiricahua living to the south called
them Ben-et-dine or binii?e'dine' (“brainless people”, “people without
minds”, i.e. "wild", "crazy", "Those who you don’t understand").[1] The
neighboring Western Apache ethnonym for them was Koun'nde ("wild rough
People"), from which the Spanish derived their use of Tonto ("loose",
"foolish") for the group. The kindred but enemy Navajo to the north
called both, the Tonto Apache and their allies, the Yavapai, Dilzhʼíʼ
dinéʼiʼ - “People with high-pitched voices”)."

Andy

[Geoff]

On Tue, 2 Feb 2016 21:16:12 +0000, Vir Campestris
<vir.cam...@invalid.invalid> wrote:

>On 02/02/2016 00:56, Jerry Stuckle wrote:
>> On 2/1/2016 4:20 PM, Vir Campestris wrote:
>>> On 01/02/2016 20:07, Jerry Stuckle wrote:
>>>> Actually, it comes from even before that - the first radio broadcast
>>>> when the Lone Ranger legend began. Except it was the Lone Ranger who
>>>> call Tonto "Kemo sabe", not the other way around.
>>>
>>> Who are you calling tonto?
>>>
>>> <http://www.spanishdict.com/translate/tonto>
>>>
>>> (I didn't know that when I was a kid...)
>>>
>>> Andy
>>
>> Tonto was an American Indian name (I forget which tribe), not Spanish.
>> Tonto was the name of the Lone Ranger's partner.
>>
>I thought you might be on to something when I found this
>
><https://en.wikipedia.org/wiki/Tonto_Apache>
>
>Then I read on...
>

>"The Tonto Apache (Dilzh??’é, also Dilzhe'e, Dilzhe’eh Apache) is one of

>the groups of Western Apache people. The term is also used for their
>dialect, one of the three dialects of the Western Apache language (a
>Southern Athabaskan language). The Chiricahua living to the south called
>them Ben-et-dine or binii?e'dine' (“brainless people”, “people without
>minds”, i.e. "wild", "crazy", "Those who you don’t understand").[1] The
>neighboring Western Apache ethnonym for them was Koun'nde ("wild rough
>People"), from which the Spanish derived their use of Tonto ("loose",
>"foolish") for the group. The kindred but enemy Navajo to the north

>called both, the Tonto Apache and their allies, the Yavapai, Dilzh?í?
>diné?i? - “People with high-pitched voices”)."
>
... which pretty well proves racism is not the sole purview of the
whites.

In the original radio series Tonto was Potawatomi nation. Ke-mo sa-be
was what he called the Lone Ranger. This was repeated in the
television series starring Clayton Moore and Jay Silverheals.

Since Tonto was a complete fiction and a product of writers who may or
may not have been cognizant of native American culture it's not
surprising that the name translates badly into other languages. The
name was probably selected to be short and to sound better than
"Fred".

Another name that translated badly into Spanish was Chevy Nova.