You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Notice that the method is listed as Packrat > metadata rather than Packrat > CollectionContainer > metadata. I can easily see why: I'm defining the method in the block passed to Struct.new, and cane doesn't realize that it's being defined on the CollectionContainer class since it's not the normal class CollectionContainer ... end style class definition.
It'd be reasonable to simply say "this isn't supported by cane", but if it wasn't too difficult, it'd be nice. I prefer defining struct classes using this block form over class CollectionContainer < Struct.new because the latter form subclasses a subclass of Struct (since Struct.new returns a Struct subclass) and therefore has an extra class in the ancestor chain, which can slow down method dispatch a bit by giving ruby an extra stop on the list of ancestors it traverses when dispatching methods.
If something is done to handle this case, it can be applied to defining classes using Class.new { ... } as well, since it's basically the same issue.
The text was updated successfully, but these errors were encountered:
I've got a class defined like so:
The output from the ABC check is:
Notice that the method is listed as
Packrat > metadata
rather thanPackrat > CollectionContainer > metadata
. I can easily see why: I'm defining the method in the block passed toStruct.new
, and cane doesn't realize that it's being defined on the CollectionContainer class since it's not the normalclass CollectionContainer ... end
style class definition.It'd be reasonable to simply say "this isn't supported by cane", but if it wasn't too difficult, it'd be nice. I prefer defining struct classes using this block form over
class CollectionContainer < Struct.new
because the latter form subclasses a subclass ofStruct
(sinceStruct.new
returns aStruct
subclass) and therefore has an extra class in the ancestor chain, which can slow down method dispatch a bit by giving ruby an extra stop on the list of ancestors it traverses when dispatching methods.If something is done to handle this case, it can be applied to defining classes using
Class.new { ... }
as well, since it's basically the same issue.The text was updated successfully, but these errors were encountered: