tag:blogger.com,1999:blog-8341844892564516905.post4772782183194337443..comments2023-11-02T01:22:19.726-07:00Comments on Ruby Eye for the Java Guy: Lost a Safety NetUnknownnoreply@blogger.comBlogger2125tag:blogger.com,1999:blog-8341844892564516905.post-48027564578348293162009-07-30T08:48:34.046-07:002009-07-30T08:48:34.046-07:00Does this merit a comment to core "throw a wa...Does this merit a comment to core "throw a warning if you mixin something that overrides previously defined variables?"Roger Packhttps://www.blogger.com/profile/01578246846716577925noreply@blogger.comtag:blogger.com,1999:blog-8341844892564516905.post-3135839785685824142008-11-24T07:05:00.000-08:002008-11-24T07:05:00.000-08:00I agree this is annoying. The manual says:For the ...I agree this is annoying. The manual says:<BR/><BR/><I><BR/>For the most part, mixin modules don't try to carry their own instance data around---they use accessors to retrieve data from the client object. But if you need to create a mixin that has to have its own state, ensure that the instance variables have unique names to distinguish them from any other mixins in the system (perhaps by using the module's name as part of the variable name).<BR/></I><BR/><BR/>Like certain other interpreted languages, Ruby gives you the tools to shoot yourself in the foot and assumes you'll have the wisdom not to. This is less of an issue if you're only using modules that you've defined, but if you're loading 3rd party modules, it might be worth giving them a once-over to make sure nothing is going to clash.Travis Whittonhttps://www.blogger.com/profile/14592647486468034166noreply@blogger.com