Extending with multiple representers

[Steve V]

Is there a way to allow an object to be extended by multiple representer modules? If not, are there plans for it? 

I know Nick is a big fan of composition, but as it currently stands I can only make a single extend call work. If I pass multiple modules to extend, the first one wins and becomes the representer. If I call extend multiple times, then the last representer wins. It would be great if representers were truly composable. That way depending on different scopes or criteria, modules could be combined to create the desired final output without having to create a a new module or class for each combination.

Thanks,

Steve

[Nick Sutterer]

Steve - that should be working already!

Object.new.extend(LastRepresenter, FirstRepresenter)

extend works from back to front, that due to a C thing, apparently.

They only extend their properties and method to the existing, no overriding should happen! I'll look into that as I couldn't find a test to assure that.

Nick

--
You received this message because you are subscribed to the Google Groups "Roar" group.
To unsubscribe from this group and stop receiving emails from it, send an email to roar-talk+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Steve Valaitis]

I thought that that should be working, but for some reason it wasn't. This was using representable 2.0.3, and roar f27add78dea9cd1677e5f6bbf69a26b4bf5c3d95.

[Nick Sutterer]

You are right, when extending objects, it overwrites: https://github.com/apotonick/representable/blob/78b1c9b0ecde0c784e84c851c4799eabe636e78a/lib/representable.rb#L90

Reason for that is that I don't want to use respond_to? or other inflection mechanisms to test whether the object is already representable.

An idea:

song.extend(Representable[SongRepresenter, BandRepresenter])

So, representable could take care of building an explicit composite representer module. That would be slower, though.

Another idea:

song.extend(Representable::Multiple, SongRepresenter, BandRepresenter)

Where Multiple would inject some code to allow extending multiple modules. Not sure, yet, how I'd have to change the existing code.

[Nick Sutterer]

My ideas are all bullshit - it's actually extremely simple to allow what you want without breaking anything :D

[Steve Valaitis]

What's needed to make this change? If you aren't able to do it soon, I might be able to take a look at it. I just don't have any idea what's required to do it. :)

[Nick Sutterer]

I thought about it, still need to play with it. It doesn't work right away, I have to add some code. This is a mission-critical change as it affects performance big time (tm).

[Steve V]

What kind of impact on performance, and how does it impact it? Is it to do with extending large quantities of objects at a time for something like a collection, or does each extend just do a lot of work each time it happens?

[Nick Sutterer]

Well, in addition to the "impact" Ruby's extend itself has on the representing process, currently, we're copying the representable_attrs configuration to the represented object. When doing this multiple times, we need to merge it, and I need to think about this how this could affect other people. It's actually not that complicated, I just need the right occasion to dive into it.

[Bart ten Brinke]

I've opened a ticket for it on Representable.

https://github.com/apotonick/representable/issues/114

This is really biting me in a DCI/grape setup where I try to assign multiple decorators depending on the roles of the objects.

Greetings, Bart