On 19/01/11 11:37, Andrei Alexandrescu wrote:
On 1/18/11 6:00 PM, Steven Wawryk wrote:
Which is exactly what I asked you about. I understand that you must be
very busy, But how do I get you to look at the actual technical content
of something? Is there something in the way I phrase thing that you
dismiss my introductory motivation without looking into the content?
I don't mean this as a criticism. I really want to know because I'm
considering a proposal on a different topic but wasn't sure it's worth
it as there seems to be a barrier to getting things considered.
One simple fact is that I'm not the only person who needs to look at a
design. If you want to propose something for inclusion in Phobos, please
put the code in good shape, document it properly, and make a submission
in this newsgroup following the Boost model. I get one vote and everyone
else gets a vote.
Ok, thanks for this suggestion. But if developing a proposal as
concrete code is a lot of work that may be rejected, is there a way to
sound out the idea first before deciding to commit to developing it?
Looking back at our exchanges in search for a perceived dismissive
attitude on my part (apologies if it seems that way - it was
unintentional), I infer your annoyance stems from my answer to this:
How does this differ from Steve Schveighoffer's string_t,
subtract the indexing and slicing of code-points, plus a
bidirectional grapheme range?
No, this was just a summary. Here is the post that you answered
dismissively: news://news.digitalmars.com:119/ih030g$1ok1$1...@digitalmars.com
>
> In the interest of moving this on, would it become acceptable to you if:
>
> 1. indexing and slicing of the code-point range were removed?
> 2. any additional ranges are exposed to the user according to decisions
> made about graphemes, etc?
> 3. other constructive criticisms were accommodated?
>
> Steve
>
>
> On 15/01/11 03:33, Andrei Alexandrescu wrote:
>> On 1/14/11 5:06 AM, Steven Schveighoffer wrote:
>>> I respectfully disagree. A stream built on fixed-sized units, but with
>>> variable length elements, where you can determine the start of an
>>> element in O(1) time given a random index absolutely provides
>>> random-access. It just doesn't provide length.
>>
>> I equally respectfully disagree. I think random access is defined as
>> accessing the ith element in O(1) time. That's not the case here.
>>
>> Andrei
>
I happen to have discussed at length my beef with Steve's proposal. Now
in one sentence you change the proposed design on the fly without
fleshing out the consequences, add to it again without substantiation,
and presumably expect me to come with a salient analysis of the result.
I don't think it's fair to characterize my answer to that as dismissive,
nor to pressure me into expanding on it.
Sorry, I could have given more context. But you didn't discuss what I
asked, based on the observation that your detailed criticisms of Steve's
proposal all related to a single aspect of it.
Steve
