[Pharo-dev] BlueInk removal

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Nov 27 15:39:25 EST 2019


Why is there no deprecation for classes?
The class definition can belong to a deprecated package.
For more advanced feature, the deprected globals could belong to another
dictionary, a bit like Undeclared...

Le mer. 27 nov. 2019 à 21:31, ducasse <stepharo at netcourrier.com> a écrit :

> Cyril
>
> there is no deprecation for classes: yes I would have to subclass each
> class and provide old classes.
> Sorry but *****I******* repackaged, cleaned the tests, cleaned the
> baseline, made sure that the baseline is working …. of
>         - GTRecorder (not used in Pharo since 3 YEARS).
>         - Enlumineur
>
> And I do not have nor the time or energy at the end of the day to do that
> in addition
> to do all the deprecation and of course fix all the dependencies tests.
>
> Now if your message is that Pharo should stay with all that shit inside
> then perfect, I’m off.
> I have plenty of other things (and a lot more exciting to do).
>
> BTW I THE GUY THAT IS PRODUCING MIGRATOR: you see the idiot that is
> collecting all the deprecated methods
> and packaged them so that OTHERS than me can migrate.
>
> So now for Blueink then you take 5 min and change your scripts.
> So GTEvent recorder you ask alex or milton to see if we can get rid of the
> problem.
>
> I do not see why Moose is loading Roassal with it.
> To me this is a bad dependency of Roassal.
>
> If Pharo puts on itself so much constraints then at the end may be I
> should stop and do something and see
> how great this super kitchen sink will evolved.
>
> Have you ever dare to look at the BaselineOfPharo, IDE just for the fun.
>
>
>
> >> Yes, this could have been handled much better, I guess (I don't know
> the details).
> >>
> >> But for day to day work, you have to use Pharo 7, which should be 100%
> stable, while Pharo 8 is a moving target, an alpha version that is
> sometimes broken.
> >>
> >
> > Hi,
> >
> > I agree that the alpha version does not have to be stable all the
> > time, but I still don't think it justify to not deprecate things.
> >
> > When you are working on stable version only, it is still better to be
> > able to migrate your projects from one version to the other via the
> > deprecation than to have everything broken and not loadable.
> >
> > If you can't even load your code, it's much harder to fix it. So I
> > still think that we should go via deprecations. It has really a low
> > cost and make migrations so much easier. Especially it give us time
> > instead of giving us an ultimatum "You want to change of version? Then
> > you need to fix everything now".
> >
> >> Now, we still want users for Pharo 8, else there will be no feedback,
> so there are certainly two sides to this argument.
> >>
> >> Sven
> >>
> >>
> >>
> >
> >
> > --
> > Cyril Ferlicot
> > https://ferlicot.fr
> >
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20191127/712c0daa/attachment.html>


More information about the Pharo-dev mailing list