Smalltalk › Usenets › Dolphin Smalltalk

Character>>asCharacter ?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Chris Uppal-3

Character>>asCharacter ?

Is there any reason why there's no Character>>asCharacter method even though
there is an Integer>>asCharacter ?

An oversight, or would it be ideologically unsound ?

-- chris

Costas Menico

Re: Character>>asCharacter ?

It doesnt make sense to have one because asCharacter takes a character
and answers its ascii representation, an integer. The reverse of that
is to take that integer and convert it back to the ascii character.

E.g.

$a codePoint. answers 97

97 asCharacter. answers $a

costas

"Chris Uppal" <[hidden email]> wrote in message news:<[hidden email]>...
> Is there any reason why there's no Character>>asCharacter method even though
> there is an Integer>>asCharacter ?
>
> An oversight, or would it be ideologically unsound ?
>
> -- chris

Chris Uppal-3

Re: Character>>asCharacter ?

costas menico wrote:

> It doesnt make sense to have one because asCharacter takes a character
> and answers its ascii representation, an integer.

(I'm assuming that wrong-way-around conversion in the above is a typo.)

The #as* type methods generally come in a "ring" of mutually convertible
objects. E.g. consider asArray, asSet, asOrderedCollection, etc. In these
cases the #as* methods allow you to treat arrays, etc, similarly without
worrying about the specific classes because #asXXX will convert it for you /if
necessary/. That pattern would break if, for instance, Array did not implement
#asArray or if it did not answer self. The #as* methods aren't really about
/converting/ one object into another, they are about /hiding the differences
between them/.

Now one could make an argument that Integers and Characters aren't
intra-convertible in this way. If you take that line then integer>>asCharacter
should not exist, and neither should Character>>asInteger.

OTOH one could say that Integers and Characters are almost the same since (in
many contexts) a Character can be identified with its code-punt. If you see it
that way, then Integer>>asCharacter and Character>>asInteger are fine, but then
you'd expect to find Integer>>asInteger and Character>>asCharacter implemented
too. In the current Dolphin code base, the second of these is missing.

-- chris

jas

Re: Character>>asCharacter ?

Chris Uppal wrote:

> costas menico wrote:
>
>
>>It doesnt make sense to have one because asCharacter takes a character
>>and answers its ascii representation, an integer.
>
>
> (I'm assuming that wrong-way-around conversion in the above is a typo.)
>
> The #as* type methods generally come in a "ring" of mutually convertible
> objects. E.g. consider asArray, asSet, asOrderedCollection, etc. In these
> cases the #as* methods allow you to treat arrays, etc, similarly without
> worrying about the specific classes because #asXXX will convert it for you /if
> necessary/. That pattern would break if, for instance, Array did not implement
> #asArray or if it did not answer self. The #as* methods aren't really about
> /converting/ one object into another, they are about /hiding the differences
> between them/.
>
> Now one could make an argument that Integers and Characters aren't
> intra-convertible in this way. If you take that line then integer>>asCharacter
> should not exist, and neither should Character>>asInteger.
>
> OTOH one could say that Integers and Characters are almost the same since (in
> many contexts) a Character can be identified with its code-punt. If you see it
> that way, then Integer>>asCharacter and Character>>asInteger are fine, but then
> you'd expect to find Integer>>asInteger and Character>>asCharacter implemented
> too. In the current Dolphin code base, the second of these is missing.
>
> -- chris

Agreed.

These things are "missing" all over the place,
and this is not confined to Dolphin.

Neither is it confined to issues of full circularity,
although that's a great description for many cases.

For example,
ReadStream>>readStream
is also "missing", but not because
ReadStream>>asString
is also missing.

In this case, the reason is found here:

>>doSomethingWith: stringOrStream
| rs |
rs := stringOrStream readStream.
.
.
.

The upside is that you either do this, or not.
So collision of method names isn't very likely.
I just add them as I encounter the need.

Regards,

-cstb

Blair McGlashan-3

Re: Character>>asCharacter ?

In reply to this post by Chris Uppal-3

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> Is there any reason why there's no Character>>asCharacter method even
> though
> there is an Integer>>asCharacter ?
>
> An oversight, or would it be ideologically unsound ?

The latter. Integer>>asCharacter is unsound, and not just ideologically;
there is an infinite range of Integer's for which the conversion does not
make sense, and of course Integers and characters are only equivalent if one
thinks in 'C', they certainly don't meet the criteria of supporting
compatible protocols. So we would rather not have included
Integer>>asCharacter either, but as I recall it was in Smalltalk-80 so we
added it for the sake of compatibility.

Regards

Blair

Blair McGlashan-3

Re: Character>>asCharacter ?

In reply to this post by jas

"cstb" <[hidden email]> wrote in message news:[hidden email]...
>...
> ReadStream>>readStream
> is also "missing", but not because
> ReadStream>>asString
> is also missing.
>...

String>>readStream is not a conversion, but a convenience shortcut. It
probably shouldn't use a selector that suggests an accessor, but at least it
doesn't suggest it is a conversion.

Regards

Blair

jas

Re: Character>>asCharacter ?

In reply to this post by Blair McGlashan-3

Blair McGlashan wrote:

> "Chris Uppal" <[hidden email]> wrote in message
> news:[hidden email]...
>
>>Is there any reason why there's no Character>>asCharacter method even
>>though
>>there is an Integer>>asCharacter ?
>>
>>An oversight, or would it be ideologically unsound ?
>
>
> The latter. Integer>>asCharacter is unsound, and not just ideologically;
> there is an infinite range of Integer's for which the conversion does not
> make sense, and of course Integers and characters are only equivalent if one
> thinks in 'C', they certainly don't meet the criteria of supporting
> compatible protocols. So we would rather not have included
> Integer>>asCharacter either, but as I recall it was in Smalltalk-80 so we
> added it for the sake of compatibility.
>
> Regards
>
> Blair

[| a b |
a := aString collect: [:each| each asInteger asCharacter].
b := aString collect: [:each| each asCharacter].
a = b ifTrue: ['makes sense']
ifFalse: ['makes no sense']
] on: Error do: [:ex| ^#cipherString:]

==

a := #() asOrderedCollection.
b := a asArray.
a add: #supportCommonProtocols.
b add: #supportCommonProtocols.

==

a := #().
b := OrderedCollection new.
c := a asOrderedCollection.
d := b asOrderedCollection.
c add: #supportCommonProtocols.
d add: #supportCommonProtocols.
a inspect.
b inspect.

==

It would take some work to actually make this consistent.

I understand Kent's argument that asThing should only be
implemented when receiver and thing supportCommonProtocols,
but I'm not sure the result is all that valuable, even to
pedantic. I could just as easily be convinced that saying
asThing is just shorthand for (Thing from: self printString),
and is sufficiently motivated by convenience. After which
I would be happy to discover that while asThing will short-
circuit wherever it can, asThingCopy will *always* return
a new object, and that everyone always implements both.

`Course I also do this:

Object>>asString
^self displayString

so I'm already non-standard. ;-)

Regards,

-cstb