On Thu, Feb 11, 2010 at 2:59 PM, Andreas Raab <andreas.raab at gmx.de> wrote:

> Eliot Miranda wrote:
>
>> this in the thread spawned by Torsen's posting of Kent's most excellent
>> rant:
>> ttp://www.threeriversinstitute.org/blog/?p=466 <
>> http://www.threeriversinstitute.org/blog/?p=466>
>>
>> <http://www.threeriversinstitute.org/blog/?p=466>OK, fix is to two
>> implementations of digitValue:.  BTW, I haven't fixed Character
>> class>>digitValue: which at least in my Teleplace image looks horribly
>> broken, answering characters not integers.  Check your distro, it may also
>> be broken
>>
>
> It's not. It works precisely as advertised (rtfc). What's confusing is that
> EncodedCharset and Unicode use the selector #digitValue: when the selector
> should be called #digitValueOf: (i.e., returning the digit value OF a
> character not creating a new character with a given digit value in this
> character set).
>

Doh!


>
> Besides, I very much doubt that the change in hex literals (which I'm very
> much in favor of btw!) will address Kent's issue.


I agree.  But every little bit helps :)


> The reality is that there's no way to address his issues because there's no
> single owner of the brand. Balkanization (which is precisely the right term)
> happens when you don't have a strong central power which can keep everyone
> at bay (such as Yugoslavia did before it fell apart). Java for example is
> owned by Sun and Sun went to court with Microsoft to ensure brand integrity.
> Unless you have an owner of "Smalltalk" (whatever that is) there isn't going
> to be a consistent set of libraries because everyone can and will push into
> different directions.
>

I disagree.  I think the community has managed to agree on the utility of
several things.  Many of the Squeak collection extensions have found their
way into VisualWorks for example because they're clearly useful and
convenient.  I think the problem with the standard is architectural, and
that that architectural limitation was built-in from the get-go  It was
intended to be something the vendors could agree upon, not a useful
standard.  The issue for the vendors was in having a check-box for Smalltalk
compared to other languages; C had a standard, C++ had a standard, so
Smalltalk needed one.  ut the standard wasn't useful for the community, and
I think as a result hasn't been that useful for the vendors.  Being
x3j20-compatible didn't mean enough.

But at the time things were very different.  Test suites were not in
widespread use and no one had developed one yet.  A good thing to come out
of x3j20 and the first CampSmalltalk was a test suite.  The web was in its
infancy; there was no javadoc or www.python.org/doc/.  Squeak was very
young.  So it's not surprising that the standard failed to be that useful.
 The world changed very quickly soon there-after.

A differently-architected standard could be useful and a gently unifying
force.  But it needs to address the challenges of standardising Smalltalk as
it exists in its current context, not as it was in the early 90's.


> Cheers,
>  - Andreas
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100211/dfeee4fd/attachment.htm