Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What is the purpose of isCasedLetter: #5274

Closed
Ducasse opened this issue Nov 30, 2019 · 4 comments
Closed

What is the purpose of isCasedLetter: #5274

Ducasse opened this issue Nov 30, 2019 · 4 comments

Comments

@Ducasse
Copy link
Member

@Ducasse Ducasse commented Nov 30, 2019

isCasedLetter: char
"There are no ASCII Characters in this Category"
^ false

isCasedLetter: char
"There are no Unicode Characters in this Category"
^ false

isCasedLetter: char
^ Unicode isCasedLetter: char

so it is always false?

There are no sender.
I propose to remove it.

@Ducasse

This comment has been minimized.

Copy link
Member Author

@Ducasse Ducasse commented Dec 3, 2019

After reading and commenting all the class I think that this method should be moved to the testing unicode and can stay there.
BTW we always deprecate methods. I'm the guy that collect deprecated methods in the Migrator package. So I know what is deprecation and I practice it daily.
No need to get lessons. Now I do not like to deprecate full packages that can be loaded externally because we get a lot a code in the middle of our process for not much.

@Ducasse Ducasse closed this Dec 3, 2019
@astares

This comment has been minimized.

Copy link
Member

@astares astares commented Dec 4, 2019

@Ducasse

Yes - and if we apply it the way you described it will be different each time and totally confusing. The effect will simply be:

  • Code that still calls a deprecated method in a still included package (normal or Deprecated80) is then able to work in the iteration release and can include a transformation (be migrated easily with due to the known deprecation or even automagic via transformation)
  • Code that still calls a deprecated method in a deprecated but removed full package can not be migrated, and also a transformation makes no sense because the package is not available in this release anymore

These call will simply fail leaving the user confused - he can not know what happened because the package is not there anymore. It was not deprecated - it was removed and surprisingly disappeared
So he can not even check where the method is to see that it was deprecated and will have a hard time finding the right package to get it back in case it is just required or he want to find a new way doing things. So the user does not know where to find the package when he tries to load and adopt his code in the iteration release - and he has a bad surprise.

Why should we follow an own Pharo route of deprecation when there is a common and easy practice in software projects for deprecations equally for packages, classes, methods:

  • you mark the artefact for removal and keep it at least one or more iterations so people get aware of the upcoming removal / migration situation
  • then you remove in the next iteration

This is easy and gives a chance for easy adoption and follows what other technologies are doing as well. And we have so far followed such a model easily with

  • using deprecations, moving to a "DeprecatedXXX" package as well as #isDeprecated
    on class side or manifest

I though we wanted to align with the outside non-Smalltalk world?

If you are up for a fast diet for the image then we can even hand out two images at release date: one

  • Pharo80-compatibility (including the deprecated methods, classes) - easing migrations
  • Pharo80-slim (with deprecations/deprecated packages already removed as we do in P9 iteration anyway)
@astares

This comment has been minimized.

Copy link
Member

@astares astares commented Dec 7, 2019

@Ducasse

This comment has been minimized.

Copy link
Member Author

@Ducasse Ducasse commented Dec 7, 2019

You can send your advices to the Pharo board or the mailing-list and the community and the consortium crew can decide. I'm not involved anymore in such decision. I'm not in mailing-lists, I'm on discord anymore, I do not look at PRs, I do not add bug entries, I do not participate to public things, I quit the board. I do not want to have any public interaction around Pharo anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.