Collections : abstract class stepping around bad request in code subclass should implement ?
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
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 <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
-- Mariano http://marianopeck.wordpress.com
Oh thanks - glad to see there has been discussion around this. I spend a lot of my time serializing objects in the Curl web content language these days, which has its own issues ;-) i.e. Curl classes can be declared serializable and there is a compiler setting for "strict serialization" but a CharClass object cannot be serialized and so it goes ( or whatever it was Kurt Vonnegut would have us all recall ;-) And the relevant code is not yet open source ! At least I am away from CORBA C-style declarations for marshalling objects (for the time being ... ) R space-like separations, time-like separations, strreamed-CLUNK-separations
participants (2)
-
Mariano Martinez Peck -
Robert Shiplett