<div dir="ltr">Aloha folks,<br><div><br></div><div>I've been experiencing and reflecting on this kind of scenario lately (e.g. add #inspectorClass to an object), and even though it is a solution to the kind of problems mentioned in this thread, I feel that assigns objects a responsibility they shouldn't have (e.g. the #inspectorClass is not part of the domain model by, say, a Product).</div><div><br></div><div>Of course, as Mariano mentioned, an alternative design and solution for that is another story.</div><div>e.g. why restrict ourselves to just one inspector? We could ask all available inspectors if they are able to inspect a given object, removing the responsibility from the object and putting that on the inspectors.</div><div><br></div><div>Keeping in line with what Mariano and Juan commented before, I found out that asking an object for the class of something they relate to (e.g. #inspectorClass) is less flexible than asking the object for the object itself (e.g. foo inspector).</div><div>The reason is that #inspectorClass imposes a protocol on the returned class. That is, they should all be instantiated using #new. If my inspector have dependencies, then I might be forced to fetch them from a "global" place, making it more coupled and difficult to test.</div><div><br></div><div>This in particular happened to me when I wanted to change the object that does highlighting on Smalltalk code. </div><div>My "highlighter" needed dependencies but the code asks for the highlighter class, so I had to create yet another object that responds to #new, and when that message is sent I create the actual highlighter.</div><div><br></div><div>My two cents.</div><div><br></div><div>Cheers,</div><div>Nico PM</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 29, 2021 at 12:19 PM Juan Vuletich via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/29/2021 11:58 AM, Mariano Montone via Cuis-dev wrote:<br>
> El 29/6/21 a las 11:54, Juan Vuletich via Cuis-dev escribió:<br>
>>> Even better than that would be to let the current selected model<br>
>>> participate in the building of the explorer menu, but I guess that would<br>
>>> be another story.<br>
>> Yes. That is a good idea. I guess that Object could answer #() to<br>
>> something like #inspectorMenuOptions, and each class could add its own.<br>
>> This should be used both for inspectors and explorers, and integrated in<br>
>> #fieldListMenu , including what currently is at<br>
>> #addItemsFromDictionaries: , #suggestObjectSpecificMenuItemsFor: , etc.<br>
> Yeah. Perhaps less intrusive could be to implement using #respondsTo:,<br>
> so that Object protocol doesn't need to be touched.<br>
><br>
> Like this:<br>
><br>
> (model respondsTo: #someMenuBuilder:) ifTrue: [<br>
>       model someMenuBuilder: myMenu].<br>
><br>
> Cheers,<br>
><br>
> Mariano<br>
<br>
I prefer to avoid calling things like #respondsTo: or #isKindOf: if <br>
possible. I think in this case, like #inspectorClass, adding to Object <br>
is reasonable.<br>
<br>
Cheers,<br>
<br>
-- <br>
Juan Vuletich<br>
<a href="http://www.cuis-smalltalk.org" rel="noreferrer" target="_blank">www.cuis-smalltalk.org</a><br>
<a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev" rel="noreferrer" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a><br>
<a href="https://github.com/jvuletich" rel="noreferrer" target="_blank">https://github.com/jvuletich</a><br>
<a href="https://www.linkedin.com/in/juan-vuletich-75611b3" rel="noreferrer" target="_blank">https://www.linkedin.com/in/juan-vuletich-75611b3</a><br>
@JuanVuletich<br>
<br>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><br>Nicolás Papagna</div>