Why Strings as Classes?

Nick Sabalausky a at a.a
Tue Aug 26 15:38:41 PDT 2008


"Denis Koroskin" <2korden at gmail.com> wrote in message 
news:op.ugie28dxo7cclz at proton.creatstudio.intranet...
> On Tue, 26 Aug 2008 23:29:33 +0400, superdan <super at dan.org> wrote:
> [snip]
>>> The D spec certainly doesn't make any guarantees about
>>> the time/memory complexity of opIndex; it's up to the implementing class
>>> to do so.
>>
>> it don't indeed. it should. that's a problem with the spec.
>>
>
> I agree. You can't rely on function invokation, i.e. the following might 
> be slow as death:
>
> auto n = collection.at(i);
> auto len = collection.length();
>
> but index operations and properties getters should be real-time and have 
> O(1) complexity by design.
>
> auto n = collection[i];
> auto len = collection.length;

I disagree. That strategy strikes me as a very clear example of breaking 
encapsulation by having implementation details dictate certain aspects of 
the API. At the very least, that will make the API overly rigid, hindering 
future changes that could otherwise have been non-breaking, 
behind-the-scenes changes.

For realtime code, I can see the benefit to what you're saying. Although in 
many cases only part of a program needs to be realtime, and for the rest of 
the program's code I'd hate to have to sacrifice the encapsulation benefits.





More information about the Digitalmars-d mailing list