Why Strings as Classes?

superdan super at dan.org
Tue Aug 26 15:56:43 PDT 2008


Nick Sabalausky Wrote:

> "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.

take this:

auto c = new Customer;
c.loadCustomerInfo("123-12-1234");

that's all cool. there's no performance guarantee other than some best effort kinda thing `we won't sabotage things'. if you come with faster or slower methods to load customers, no problem. coz noone assumes any.

now take sort. sort says. my input is a range that supports indexing and swapping independent of the range size. if you don't have that just let me know and i'll use a totally different method. just don't pretend.

with that indexing and swapping complexity ain't implementation detail. they're part of the spec. guess stepanov's main contribution was to clarify that.

> 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.

realtime has nothin' to do with it. encapsulation ain't broken by making complexity part of the reqs. any more than any req ain't breakin' encapsulation. if it looks like a problem then encapsulation was misdesigned and needs change.

case in point. all containers should provide 'nth' say is it's o(n) or better. then there's a subclass of container that is indexed_container. that provides opIndex and says it's o(log n) or better. it also provides 'nth' by just forwarding to opIndex. faster than o(n) ain't a problem. but forcing a list to blurt something for opIndex - that's just bad design. 



More information about the Digitalmars-d mailing list