On Tue, Jan 3, 2017 at 8:56 PM, Eliot Miranda <[email protected]> wrote:
> > > 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; >> > Yes, but it depends mostly on the user and there is no automated check for it... So it happens that people (myself also) sometimes remove stuff without going into the deprecation phase... :/ > 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 don't think step 1 is mandatory. Actually I would say it should be forbidden. Why should Smalltalk be a facade for every library in the system? I agree however that for library/method rewrites we should at least keep the old interface if possible. Now, when it happens that the new API is not compatible with the old one, only the migration should be nicely documented... >> 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. >> > I'd say that's life... > 2) The deprecated message above is wrong, the Smalltalk session >> unregisterClassNamed: is preferrable to referencing the class directly. >> > And that this requires a fix om the docs. > 3) The deprecated method does nothing, rather than redirect to the new >> place. Silent errors when deprecation warnings are turned of, yay. >> > Well redirection should be done wether it is possible. But if it is not, then the method should be cancelled with an exception? Like that even if the deprecation is ignored, the error does not go silent. > 4) The deprecation message uses the deprecated form which does not include >> the parameters needed to know when to expect it removed forever. >> > Did not get this one > >> 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. >> > I agree we should've deprecated. Maybe we can deprecate it now in Pharo6 for Pharo7 (before removing the methods from Smalltalk definitively?) > 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? > > Here I am not sure of agreeing. Going through Smalltalk is evil. Maybe asking the platform is better, to hide the "EndianDetector". > +1. EndianDetector is a monstrosity. > Ok, EndianDetector is maybe an ugly name. But it has a reason to be. Before, to test endianess the system used a Bitmap. And we wanted a standalone class that we could use whether Bitmap is there or not (by becoming an instance of a float into a bitmap or so... I don't remember the details). So, it is a badly name little child only. We can rename it. Suggestions? > >> Cheers, >> Henry >> > > _,,,^..^,,,_ > best, Eliot >
