Re: Q: type ... is new String

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Tue, 05 Jun 2012 10:40:36 +0200, Georg Bauhaus wrote:

> On 05.06.12 09:32, Dmitry A. Kazakov wrote:
>> On Mon, 04 Jun 2012 22:56:01 +0200, Georg Bauhaus wrote:
>>
>>> On 04.06.12 19:05, Dmitry A. Kazakov wrote:
>>
>>>> There is nothing ambiguous in character encoding,
>>>
>>> In processing data from any source that speaks HTTP, you don't really know
>>> the character encoding: you may be told the encoding is X but actually it
>>> is Y.
>>
>> <=>  I do know the encoding.
> 
> You snipped the part that explained how this "knowledge" isn't
> knowledge. It is in a state of flux and occasionally crystallizes
> to yield Heisentypes. ;-)
> 
> (All I see is subsequences of 2#bbbb_bbbb#. For the AI part,
> I am told to produce the most likely information that the
> originator might have intended to send.)

Bad design. Don't do that.

>> You are trying to pursue some absolute truth, e.g. "true encoding" of a
>> broken page, which simply does not exist and is irrelevant.
> 
> I am the one to create the truth, the valuable information. Like I am
> the one to guess the correct interpretation of calendar date 5/6/7.

Maybe, but that imposes no problem on software design. The mail program
successfully transmitted "5/6/7" without making guesses. Do not conflate
well-defined functionality, e.g. "send over socket", "render calendar page
on the screen" with ill-defined stuff, like what is going on in someone's
head.

>> If you want to add some encoding guessing layer, do it just elsewhere.
> 
> Too late.

For broken design it is always too late. Fix the design.

>>>> For each possible input
>>>> there is a defined output the parser should spill. Where is a problem?
>>>
>>> Here is the problem: There is no complete description of the set of
>>> possible inputs.
>>
>> See, that is the problem. People didn't do their job.
> 
> No, they did their job.

How an incomplete definition is job done?

Now feel free to tell me that working without specifications, is the right
way to develop software...

>> Nope, things changing are as irrelevant as the computer's relative position
>> to Proxima Centauri.
> 
> So what is the outline of a type that describes a file naming
> scheme that has changed?

Why should I care about description of naming schemes? I need a set of
types describing file name valid in some specified environment. It is not
rocket science. Before you start confusing things again, this has nothing
to do with parsing file names.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de