On Wed, Sep 26, 2012 at 12:19 PM, Robert Shiplett <grshiplett@gmail.com> wrote:

yes, 2.0 has that odd duplicate code (see my prev misplaced msg below ...)

A lot of time spent in expression-based languages leaves me
uncomfortable that ^self is used for this NOP condition which looks
like an unmessaged/unsignalled failure that should never arise.

I ask just me: why is this not Error material ? �Should there not be a
flag to test against as to whether this is non-recoverable
non-completion of task ?

The opponents of nil checks spend too little time in happily
back-tracking Icon dialects ? ( yes ... there is now expression-based
ObjectIcon - and it is Unicode )

Of course the real question is how this code gets to stay there at all
even in 2.0 - or shoudl I be asking why a Trait was not the cure here
?

The really good news: it was not a copy-n-paste !

But seriously ... when this failure occurs, what flags that it is
harmless ? �Compare messaging model of RTOS QNX where the cost of this
advice is low.

Or is this all safely covered by unit testing ? �( yes, that is my
twisted sense of almost-humour ... )

>
> In 1.4 ArrayedCollection we have
>
> this
>
> � � �self class isPointers | self class isWords not ifTrue: [^self].
>
> in >>restoreEndianness
>
> but this in
>
> >>writeOn:
>
> � � � � (self class isPointers or: [ self class isWords not ]) ifTrue: [^ self ].
>
> It gets called once per task in both and should be a correct method,
> right ? The former does not even look correct at a glance.
>
> I have no time today to go check if this odd duplication remains in
> 2.0 as I must run
>