tulamide wrote:Very unintuitive.
It sure is! It's one of the bits of Ruby that most often catches me out (especially when objects are nested).
Even once the
usual Ruby rules for copying are understood, there's another issue - many Ruby add-ons, including FlowStone's custom classes, don't obey the rules anyway!!
The base "Object" class has default definitions for "dup" and "clone" which work fine for most user-defined classes. But these assume that all of an object's state is stored in Ruby objects assigned to instance variables, and that's not the case for "C-extension" objects which encapsulate non-Ruby data - such as, for example, handles to GDI+ objects!
To see what I mean, try "dupping" or "cloning" some Ruby GUI objects (e.g. Brushes, Pens, GraphicsPaths etc.). The copying methods themselves won't complain, but when you try to use the returned copies, they either don't work or will crash FlowStone (on v3.0.6 at least - I should test this in the Alphas!).
To be fair, I don't recall anyone else complaining that they've run into this problem. However, all FS custom classes are kind_of?(Object), and "dup" and "clone" are part of the interface of "Object" - so in OO terms, it's
very naughty not to implement them properly! When copying is really not possible, raising a "NotImplementedError" is a valid, documented option - but returning a broken object which might later crash the interpreter is not!!