Re: Ada Interfaces and the Liskov Substitution Principle
- From: "Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx>
- Date: Wed, 30 May 2007 10:43:47 +0200
On 30 May 2007 00:40:14 -0700, Maciej Sobczak wrote:
On 29 Maj, 19:07, "Dmitry A. Kazakov" <mail...@xxxxxxxxxxxxxxxxx>
wrote:
We are talking about real:
X := Y;
Huh, how are going to design a non-referential container of T'Class?
I don't. :-)
Polymorphism and references come hand in hand if you need the ability
to reassign. Copy-initialization is the only place where you can
safely get away with "values" of T'Class.
Are you going to sell me pointers, right here, in c.l.a? (:-))
Referential semantics is an implementation detail. You propose to expose it
to defend a fiction. But it would be in vain, because assigning class-wide
references in this context is semantically equivalent to assigning the
targets.
I think that the mess has its source in the push to have T'Class
behaving like normal value.
This is all meta-programming is about: dealing with polymorphic values =
programming in terms of sets of types.
I say that you need one type String, that possibly uses strategy
internally to delegate details like encoding. You don't need encoding
to "leak out" at the level of types that the final user operates on.
That would be indeed a mess. How would you pass an UTF-8 string to GTK+
which knows nothing about your fancy patterns?
Then it should know.
It cannot, it is ANSI C.
Otherwise there is no way it can interpret
correctly what I pass as parameters, unless you want to have
"implicit" conversions for parameters.
To interpret, to convert etc, all this requires a distinct type. Which is
why different representations have to be mapped to different types.
Why don't you use the
advantages of the types system?
I do use it, I just don't elevate implementation details to the level
of type that is handled directly by the user.
I don't see any handling required. But let it be, then how is it different
from your void * approach? When you create a void * you have to somehow
specify the hidden parameter of the case-statement:
void * X = Create_UTF8 ("foo");
With types you just specify the type of the object instead:
X : UTF8_String := "foo";
You can (and should) have dispatching internally in the implementation
of operations of String. I'm not proposing any case statements here!
Here you are. What is the difference between internally and externally
dispatching assignments?
Assignment is an operation that is meaningful syntactically - that's
why it is so tempting. Internally you can have anything else,
including regular subprogram calls that will do necessary conversions.
But not assignments? The question is how do I do dispatching assignment?
Your point was that I shall not do it publicly. But, may I dispatch
privately? If yes then how? And where is any difference? If not, then the
only way left is a case-statement.
Static polymorphism does not allow mixing types.
?
Instances from a statically polymorphic class of types are unrelated types.
You cannot have any polymorphic object from that class, only specific
objects. For the same reason you cannot have any class-wide operation from
that class.
Further you cannot design
a library for formatting strings which would not be generic itself.
1. So?
Write an editor for such strings, store a string, send it over the network,
do anything after uninstalling the compiler ...
2. Yes, I can. Just use arbitrary string type for formatting and then
convert to the destination type.
Why should I bother to have UTF-8 or ASCII strings if anything is
Wide_..._Wide_Unbounded anyway? What are you going to do if the endianess
of Wide x n Character does not fit your machine?
The former is quite possible and IMO is the only right way to go. Note that
the language should also allow declaring symmetries of the methods to
reduce the number of independent variants.
Yes, but that reduces the complexity by a constant only, the problem
is still fundamentally squared.
It is how it is. No matter how you would handle them, you have to all of
them. Whatever pattern you use, you will have to deal with this number of
cases. Do you seriously propose to define some of the cases improperly,
just because there are too many of them? (:-))
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.
- Follow-Ups:
- Re: Ada Interfaces and the Liskov Substitution Principle
- From: Maciej Sobczak
- Re: Ada Interfaces and the Liskov Substitution Principle
- References:
- Ada Interfaces and the Liskov Substitution Principle
- From: Stefan Lucks
- Re: Ada Interfaces and the Liskov Substitution Principle
- From: Maciej Sobczak
- Re: Ada Interfaces and the Liskov Substitution Principle
- From: Randy Brukardt
- Re: Ada Interfaces and the Liskov Substitution Principle
- From: Maciej Sobczak
- Re: Ada Interfaces and the Liskov Substitution Principle
- From: Dmitry A. Kazakov
- Re: Ada Interfaces and the Liskov Substitution Principle
- From: Maciej Sobczak
- Re: Ada Interfaces and the Liskov Substitution Principle
- From: Randy Brukardt
- Re: Ada Interfaces and the Liskov Substitution Principle
- From: Maciej Sobczak
- Re: Ada Interfaces and the Liskov Substitution Principle
- From: Dmitry A. Kazakov
- Re: Ada Interfaces and the Liskov Substitution Principle
- From: Maciej Sobczak
- Re: Ada Interfaces and the Liskov Substitution Principle
- From: Dmitry A. Kazakov
- Re: Ada Interfaces and the Liskov Substitution Principle
- From: Maciej Sobczak
- Re: Ada Interfaces and the Liskov Substitution Principle
- From: Dmitry A. Kazakov
- Re: Ada Interfaces and the Liskov Substitution Principle
- From: Maciej Sobczak
- Re: Ada Interfaces and the Liskov Substitution Principle
- From: Dmitry A. Kazakov
- Re: Ada Interfaces and the Liskov Substitution Principle
- From: Maciej Sobczak
- Re: Ada Interfaces and the Liskov Substitution Principle
- From: Dmitry A. Kazakov
- Re: Ada Interfaces and the Liskov Substitution Principle
- From: Maciej Sobczak
- Ada Interfaces and the Liskov Substitution Principle
- Prev by Date: Re: Ada Interfaces and the Liskov Substitution Principle
- Next by Date: Re: Ada Interfaces and the Liskov Substitution Principle
- Previous by thread: Re: Ada Interfaces and the Liskov Substitution Principle
- Next by thread: Re: Ada Interfaces and the Liskov Substitution Principle
- Index(es):
Relevant Pages
|