Why Strings as Classes?

superdan super at dan.org
Mon Aug 25 17:31:06 PDT 2008


Benji Smith Wrote:

> Sorry, dan. You're wrong.

well just sayin' it ain't makin' it. hope there's some in the way of a proof henceforth.

> superdan wrote:
> > again you want to build larger components from smaller components.
> 
> Good APIs define public interfaces and hide implementation details, 
> usually providing a default general-purpose implementation while 
> allowing third-parties to define special-purpose implementations to suit 
> their needs.

sure thing. all this gave me a warm fuzzy feelin' right there.

> In D, the text handling is defined by the data format (unicode byte 
> sequences) rather than by the interface, while providing no polymorphic 
> mechanism for alternate implementations.
> 
> It's the opposite of good API design.

wait a minute. you got terms all mixed up. and that's a recurring problem that mashes your argument badly. first you say `in d'. so then i assume there's a problem in the language. but then you go on with what looks like a library thing. sure enuff you end with `api' which is 100% a library thingy.

so if you have any beef say `in phobos' or `in tango'. `in d' must refer to the language proper.

the core lang is supposed to give you the necessary stuff to do that nice api design that gave me half an erection in ur first paragraph. if the language gives me the classes and apis and stuff then things will be slow for everyone and no viagra and no herbal supplement ain't gonna make stuff hard around here.

i think d strings are the cleverest thing yet. not too low level like pointers. not too high level like classes and stuff. just the right size. pun not intended.

> The regular expression engine accepts character arrays. And that's it. 
> You want to match on a regex pattern, character-by-character, from an 
> input stream? Tough nuts. It's not possible.

there are multiple problems with this argument of yours. first it's that you swap horses in the midstream. that, according to the cowboy proverb, is unrecommended. you switch from strings to streams. don't.

about streams. same in perl. it's a classic problem. you must first read as much text as you know could match. then you match. and nobody complains.

what you say is possible. it hasn't been written that way 'cause it's damn hard. motherintercoursin' hard. regexes must backtrack and when they do they need pronto access to the stuff behind. if that's in a file, yeah `tough nuts' eh.

> The new JSON parser in the Tango library operates on templated string 
> arrays. If I want to read from a file or a socket, I have to first slurp 
> the whole thing into a character array, even though the 
> character-streaming would be more practical.

non seqitur. see stuff above.

> Parsers, formatters, console IO, socket IO... Anything that provides an 
> iterable sequence of characters ought to comply with an interface 
> facilitating polymorphic text processing. In some cases, there might be 
> a slight memory/speed tradeoff. But in many more cases, the benefit of 
> iterating over the transient characters in a stream would be much faster 
> and require a tiny fraction of the memory of the character array.

so what u want is a streaming interface and an implementation of it that spans a string. for the mother of god i can't figure what this has to do with the language, and what stops you from writing it.

> There are performance benefits to be found on both sides of the coin.

no. all benefits only of my side of the coin. my side of the coin includes your side of the coin.

> Anyhow, I totally agree with you when you say that "larger components" 
> should be built from "smaller components".

cool.

> But the "small components" are the *interfaces*, not the implementation 
> details.

quite when i thought i drove a point home... dood we need to talk. you have all core language, primitives, libraries, and app code confused.



More information about the Digitalmars-d mailing list