Why Strings as Classes?

[Fawzi Mohamed]

On 2008-08-28 06:06:11 +0200, "Nick Sabalausky" <a at a.a> said:

> "Fawzi Mohamed" <fmohamed at mac.com> wrote in message
> news:g94k2b$2a1e$1 at digitalmars.com...
>> 
>> I am with dan dee_girl & co on this issue, the problem is that a generic
>> algorithm "knows" the types he is working on and can easily check the
>> operations they have, and based on this decide the strategy to use. This
>> choice works well if the presence of a given operation is also connected
>> with some performance guarantee.
>> 
> 
> IMO, a better way to do that would be via C#-style attributes or equivilent
> named interfaces. I'm not sure if this is what you're referring to below or
> not.

yes categories are basically named interfaces for types, unlike the 
constraint (that check if something is implemented) one has to 
explicitly say T implements Interface (and obviously T has to have all 
the requested functions/methods).
This should be available for all types, and you should be able to 
request also the existence of free functions, not only of methods.
Attributes are a simplified version of this (basically no checks for a 
given interface).
The important thing is that presence or absence of attributes in a 
given type is not automatically inferred from the presence of given 
functions.

>> Concepts (or better categories (aldor concept not C++), that are
>> interfaces for types, but interfaces that have to be explicitly assigned
>> to a type) might relax this situation a little, but the need for some
>> guarantees will remain.
>> 
> 
> If this "guarantee" (or mechanism for checking the types of operations that
> a collection supports) takes the form of a style guideline that says "don't
> implement opIndex for a collection if it would be O(n) or worse", then that,
> frankly, is absolutely no guarantee at all.

well if it is in the spec and everybody knows it, then breaking it and 
getting bad behavior is you own fault.

> If you *really* need that sort of guarantee (and I can imagine it may be
> useful in some cases), then the implementation of the guarantee does *not*
> belong in the realm of "implements vs doesn't-implement a particular
> operator overload". Doing so is an abuse of operator overloading, since
> operator overloading is there for defining syntactic sugar, not for acting
> as a makeshift contract.
> 
> The correct mechanism for such guarantees is with named interfaces or
> C#-style attribtes, as I mentioned above. True, that can still be abused if
> the collection author wants to, but they have to actually try (ie, they have
> to lie and say "implements IndexingInConstantTime" in addition to
> implementing opIndex). If you instead try to implement that guarantee with
> the "don't implement opIndex for a collection if it would be O(n) or worse"
> style-guideline, then it's far too easy for a collection to come along that
> is ignorant of that "psuedo-contract" and accidentially breaks it. Proper
> use of interfaces/attributes instead of relying on the existence or absense
> of an overloaded operator fixes that problem.

I fully agree that with interfaces (or categories or attributes) the 
correct thing is to use them to enforce extra constraints, so that 
overloading (or naming the functions) is really just syntactic sugar, 
but also in this case it can make reading (and writing from the 
beginning reasonably fast code) and understanding complexity (speed) of 
code reading it easier if some social contract about speed of 
operations is respected.

Pleas note that these "guarantees" are not such that one cannot break 
them, their purpose is to make the life of who knows them and enforces 
them easier, and also of the whole community if it chooses to adopt it. 
As Steve just argued much more fully than me.

STL, does it, and I think that also in D should do it, should D get 
categories or attributes this things could be relaxed a little, but I 
think there will still be cases where expecting a given function to 
have a given complexity will be a good thing to have.

It just makes thinking about the code easier, and simpler to stay at 
high level without having surprises that you have to find out by 
looking in detail at the code, and so it makes a programmer more 
productive.

Fawzi