开发者

Best way to extend Pharo Smalltalk class behavior?

开发者 https://www.devze.com 2023-02-07 20:28 出处:网络
I want to extend the String class with a method to create a url slug out of a st开发者_如何学JAVAring. I found a link here that shows how you can move extensions to their own package:

I want to extend the String class with a method to create a url slug out of a st开发者_如何学JAVAring. I found a link here that shows how you can move extensions to their own package:

Smalltalk Daily 07/13/10: Extending Behavior II.

However, I can't find any "move to package" option in Pharo Smalltalk. Is it ok to just extend the core class with the new method, or is there a better way?


In Pharo or Squeak put the extension methods for MyPackage in a method category called *mypackage (or if you want to be more descriptive *mypackage-slug).

The methods in these categories belong automatically to the MyPackage package (at least from the Monticello point of view)


"Is it ok to just extend the core class with the new method, or is there a better way?"

There are tradeoffs to this decision. In fact, Pharo had String>>asUrl until very recently, when it was removed as part of cleaning the system. On one hand, it is considered bad style by some (see Kent Beck's Best Practices) to have conversion methods between objects that do not have similar protocols (are semantically similar). Additionally, this leads to bloated core classes (like String and Object). However, in your own application, there may be a good reason that balances these factors, and since you are packaging it with your app, and not with the system, rock out.


In pharo 7, * is forbidden.

A message tells you have to tick the extension checkbox in method edition pane.

If you do so, you can choose your package.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号