On 4 Jun., 15:49, Leslie Viljoen <leslievilj... / gmail.com> wrote:
> Sorry to beat a dead horse, but to confirm: the only way to mix a
> module into an already
> existing class it to reopen it with something (ugly) like this:
>
> class String; include Crc; end
>
> (1) Is that right?
>
> And then to mix a module into an instantiated object, you can use
> extend, and that
> modifies the one object. (2) Philosophically, is there any reason why
> extend can't be used
> in the same way on classes? (ie. String.extend(Crc))

You need to be able to distinguish between importing class methods and
importing instance methods (see Stefano's reply).

> One other question (3), below is an example of my SelfCrc module. This module
> works well when included into String, but extend doesn't work because that
> only modifies the one object and .crc16_ok? below tries to call .get_crc16
> on a new string that it creates, which fails.
>
> I can modify it to work like so:
>
>         def crc16_ok?
>                 first_part = self[0..-3]
>                 first_part.extend(SelfCrc)
>                 first_part.get_crc16 == get_terminating_crc16
>         end
>
> ..is that the right way to make this module work properly? Or are
> some modules just not suitable for extend?

If your module expects to be present in all instances of the class
then including is the only reasonable way to do it IMHO.

I can think of a number of other designs which would not have this
issue but since I do not exactly know what your module does
(especially CrcTab which could be a kind of cache) I am reluctant to
enumerate them.

Assuming that you want to store strings along with their CRC's I'd
rather have a separate class that has a String and a CRC.  That seems
more natural to me.  This would also avoid the issue that you cannot
easily determine whether a String does contain its CRC or not etc.

Kind regards

robert