I think this issue is related: http://code.google.com/p/pharo/issues/detail?id=2230
On Wed, Sep 26, 2012 at 12:19 PM, Robert Shiplett <[email protected]>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 > > > > -- Mariano http://marianopeck.wordpress.com
