On Tue, Jan 3, 2017 at 2:24 AM, Henrik Johansen < [email protected]> wrote:
> It was my impression there was a procedure in place earlier for moving > methods from SmalltalkImage to classes with a more singular responsibility > that ensures a smooth upgrade experience; > 1) create accessor method on Smalltalk (if none of the existing are > appropriate) > 2) implement the old methods on new class in backwards compatability > category > 3) Deprecate method on SmalltalkImage, on the form: > doX: someThing > self deprecated: 'Use Smalltalk specializedArea x: someThing > instead' on: 'foo' in: 'bar'. > ^self specializedArea x: someThing > > (Ref: #os, #vm) > > I've run into a few cases where this is not the case when moving to Pharo > 5, should they be changed, or am I wrong, and the procedure above is no > longer considered valuable? > > Case 1: > SmalltalkImage removeFromShutDownList: aClass (and removeFromStartUpList:) > self deprecated: > 'Please use registration methods provided in > SessionManager / registration category.', > String cr, > 'ex: SessionManager default unregisterClassNamed: self > name'. > > There's a new #session accessor on SmalltalkImage, but... > 1) SessionManager does not implement a backwards compatible protocol. > 2) The deprecated message above is wrong, the Smalltalk session > unregisterClassNamed: is preferrable to referencing the class directly. > 3) The deprecated method does nothing, rather than redirect to the new > place. Silent errors when deprecation warnings are turned of, yay. > 4) The deprecation message uses the deprecated form which does not include > the parameters needed to know when to expect it removed forever. > > Also, the corresponding addTo... methods have not been deprecated, but > redirect to SessionManager directly rather than through #session... > > Case 2: > EndianDetector: Used to be Smalltalk #endianness > > 1) The method on SmalltalkImage has simply been removed, no deprecation. > 2) Accessor remains the same, but all references in the base image has > been rewritten to use EndianDetector directly... > 2) Would not Smalltalk platform be a reasonable place to put this > responsiblity, letting it use an EndianDetector behind the scenes? Both the > preexisting #endianness, as well as the new #isLittleEndian and > #isBigEndian? > +1. EndianDetector is a monstrosity. > Cheers, > Henry > _,,,^..^,,,_ best, Eliot
