Re: Musing on defining attributes and the ability to define an "abstract type X"-interface.

["Randy Brukardt" <randy@rrsoftware.com>]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:202c2f80-ad58-4fac-9fff-e064fed782a9@googlegroups.com...
...
>That is what this proposal is about, not OOP or keyword 
>"Interface"/"Abstract",
>but bringing things together so that the whole current type-system can be
>described uniformly in this new manner... and that is the key: UNIFORMLY.

No one is going to take this on, or even allow it to be done. It would cause 
dozens (probably hundreds) of bugs in the Standard's wording, which would 
have to be fixed down the road. (Just look at the number of bugs that adding 
preconditions, a much smaller change, caused.)

See also my response to Dmitry.

It doesn't matter if something is *better* (whatever that means), it matters 
if it is compatible with the current definition, it matters if the costs to 
implement it (both in the wording of the language standard and in 
implementations) are cheap enough, and it matters whether the problems that 
it will solve are important.

The only way to avoid spending all of our very limited time on way-out ideas 
that may lead nowhere is to very strictly ask for problems that need 
solving. The string mess needs solving, and preferably without adding 
Wide_Wide_Open to every I/O unit. No one has any problems for integer types 
that I know of.

>Even you yourself have scratched the surface in recognizing that
>[[Wide_]Wide_]String ought to have a "base class" -- though
>your solution (ie Root_String_Type) is a specific solution where
>if a general solution like this were proffered we could do things
>like: have containers with the interface of "array" [ie C'Length, C'First, 
>etc].

It would be better if arrays had a container interface, IMHO. The whole idea 
of an array is a rather archaic one, and it would be best if they were 
simply forgotten about. Moreover, we're only talking about a single 
character difference (C.Length vs. C'Length).

I was trying to solve the only real problem with strings, which is dealing 
with string literals. Even if you made some sort of overall generalization, 
you'd still need a special case for strings because you have to deal with 
string literals.

So, I don't see it; in any case, you need to show the problems that are 
being solved. Lack of uniformity is not a problem, per-se; it would be 
completely impossible to make a language that was completely uniform. 
(Tucker used to explain this as "bump under the rug" issues: you can move 
the bump around, but there is no way to actually eliminate it.)

                                              Randy.