Prev: Using snack with -blocking
Next: Thread question regarding vwait
From: Neil Madden on 22 Nov 2009 12:55
tom.rmadilo wrote:
> On Nov 21, 4:25 am, Neil Madden <n...(a)cs.nott.ac.uk> wrote:
> ... (see previous post)
>
> All I can say is that you are mixing up two different points that I
> was trying to make.
>
> I am not saying that subtyping cannot be used to represent subtypes or
> "kind of" relationships. Never even got close to that.
>
> My point is simple: subtyping breaks the definition of a type/class/
> interface over many different files, Java is a good example regardless
> of extends or implements. Both are top-down and fixed. They require
> prior understanding of the similarities and relationships (the model)
> before you can create the type/class/interface hierarchy. Changes are
> difficult to introduce. The subtyping is a language feature and
> represents a different style of programming.

This is incorrect. There is a world of difference between the keywords
"implements" and "extends" in Java. Firstly, subtyping -- either as a
concept, or as realised in Java -- does not require you to split your
implementation over several files, or over several classes. Indeed,
subtyping says nothing about implementation whatsoever.

Secondly, subtyping does not require that the class hierarchy be fixed
ahead of time. Some less flexible statically typed languages may have
this restriction, but it by no means essential.

If your point was that *inheritance* as an implementation strategy makes
code harder to follow and potentially more fragile, then that is
something I can agree with. Indeed, that seems to be the consensus view
these days. But that is an entirely different point.

>
> That was point one.
>
> Second point: You don't need these language features to get similar
> results, maybe better results. This was the whole point of my original
> "Wow, goroutines have a flat type hierarchy!" post.

You can implement subtyping in your language from other features,
indeed, but it's still subtyping.

>
> Never did I say that such features do not exist or cannot model
> something, maybe anything. It just isn't a very flexible development
> strategy.

You did say that the real world doesn't support hierarchical models. I
directly quoted you in the previous message.

>
> I also gave examples of other systems, but these were never meant to
> indicate you could not model the same thing using a hierarchical type
> system. They were instead examples of systems which develop from the
> ground up, before any hierarchy exists.
>
>
From: tom.rmadilo on 22 Nov 2009 14:47
On Nov 22, 9:55 am, Neil Madden <n...(a)cs.nott.ac.uk> wrote:
> tom.rmadilo wrote:
> > On Nov 21, 4:25 am, Neil Madden <n...(a)cs.nott.ac.uk> wrote:
> > ... (see previous post)
>
> > All I can say is that you are mixing up two different points that I
> > was trying to make.
>
> > I am not saying that subtyping cannot be used to represent subtypes or
> > "kind of" relationships. Never even got close to that.
>
> > My point is simple: subtyping breaks the definition of a type/class/
> > interface over many different files, Java is a good example regardless
> > of extends or implements. Both are top-down and fixed. They require
> > prior understanding of the similarities and relationships (the model)
> > before you can create the type/class/interface hierarchy. Changes are
> > difficult to introduce. The subtyping is a language feature and
> > represents a different style of programming.
>
> This is incorrect. There is a world of difference between the keywords
> "implements" and "extends" in Java. Firstly, subtyping -- either as a
> concept, or as realised in Java -- does not require you to split your
> implementation over several files, or over several classes. Indeed,
> subtyping says nothing about implementation whatsoever.

Oh, my! The base class is in one file, the derived class is in a
second file! Is this such a difficult thing go understand?

It also has nothing to do with being in different files. If you
"extend" something, you have to look back at what you are extending to
get an idea what the whole type looks like. That is okay for the
original developer, but if you are trying to understand the code, you
have to hunt around to find the full definition of what you are
looking at.

Of course this would be worse with multiple inheritance and for single
inheritance with much depth.

And even implements presents the same issues. Just reading through a
few of the manpages for the Java.util makes me ill.


> Secondly, subtyping does not require that the class hierarchy be fixed
> ahead of time. Some less flexible statically typed languages may have
> this restriction, but it by no means essential.

I'm talking about subtyping as a "language feature", once everything
is in memory who cares how it got there? Also, flexibility is "over
the lifetime of the project", not a runtime feature.

> If your point was that *inheritance* as an implementation strategy makes
> code harder to follow and potentially more fragile, then that is
> something I can agree with. Indeed, that seems to be the consensus view
> these days. But that is an entirely different point.

As a language feature, a language feature, as in "built into the
language". As in: in one place you define a class or type and then in
another place you refer to this type and bind a new type or class to
this base type using language keywords to instruct the compiler or
interpreter how to create the new type.


>
> > That was point one.
>
> > Second point: You don't need these language features to get similar
> > results, maybe better results. This was the whole point of my original
> > "Wow, goroutines have a flat type hierarchy!" post.
>
> You can implement subtyping in your language from other features,
> indeed, but it's still subtyping.

Who cares? Did I ever say that the system couldn't have subtypes? No.
Just not as a language feature. I haven't described any such feature.

> > Never did I say that such features do not exist or cannot model
> > something, maybe anything. It just isn't a very flexible development
> > strategy.
>
> You did say that the real world doesn't support hierarchical models. I
> directly quoted you in the previous message.

Right, you think "real world" includes everything, I don't. In the
real world objects can have an independent existence prior to
establishing some relationship with other objects. If the universe of
established relationships forms a hierarchy, great. But if the
modeling system places objects and classes into a pre-built hierarchy,
this does not reflect real world experience. Maybe the difference is
that in the system I'm describing you discover the hierarchy, but
there are other things besides hierarchy.
From: tom.rmadilo on 23 Nov 2009 11:43
On Nov 23, 3:41 am, Neil Madden <n...(a)cs.nott.ac.uk> wrote:
> tom.rmadilo wrote:
> > On Nov 22, 9:55 am, Neil Madden <n...(a)cs.nott.ac.uk> wrote:
> >> tom.rmadilo wrote:
> >>> On Nov 21, 4:25 am, Neil Madden <n...(a)cs.nott.ac.uk> wrote:
> >>> ... (see previous post)
> >>> All I can say is that you are mixing up two different points that I
> >>> was trying to make.
> >>> I am not saying that subtyping cannot be used to represent subtypes or
> >>> "kind of" relationships. Never even got close to that.
> >>> My point is simple: subtyping breaks the definition of a type/class/
> >>> interface over many different files, Java is a good example regardless
> >>> of extends or implements. Both are top-down and fixed. They require
> >>> prior understanding of the similarities and relationships (the model)
> >>> before you can create the type/class/interface hierarchy. Changes are
> >>> difficult to introduce. The subtyping is a language feature and
> >>> represents a different style of programming.
> >> This is incorrect. There is a world of difference between the keywords
> >> "implements" and "extends" in Java. Firstly, subtyping -- either as a
> >> concept, or as realised in Java -- does not require you to split your
> >> implementation over several files, or over several classes. Indeed,
> >> subtyping says nothing about implementation whatsoever.
>
> > Oh, my! The base class is in one file, the derived class is in a
> > second file! Is this such a difficult thing go understand?
>
> Yes, because it is wrong. Nothing in Java or other languages with
> subtyping says that they have to be in different files. If you want to
> do public subtyping, then the interface and the sub-type implementations
> have to be in separate files, but that is just one case.

I just love your selective quoting of what I said to make your point.
The only point being that I don't understand something (something
which I am not even talking about).

> It's clear from this conversation that you are still conflating
> subtyping with inheritance, and I cannot think of a more straightforward
> way of explaining it, so there is little point continuing. Besides, it
> seems clear also that you have retracted your initial claim that
> subtyping and class hierarchies are a bad idea.

Again, you persist in this nonsense about what I don't understand. I'm
not trying to distinguish subtyping from inheritance.

I also never retracted any statement about subtyping and
hierarchies...how could I, according to you I don't even understand
what subtyping is.

It is amazing how you take one statement and transform it into another
using different words and claim that I used those words with your
selected meaning.

What is the purpose of doing that? I understand it is always possible
to misunderstand other people because you don't catch the meaning of
the words they have chosen, but when you intentionally put your own
words in someone elses' mouth something else is going on.
 | 
Pages: 1
Prev: Using snack with -blocking
Next: Thread question regarding vwait