[Cuis-dev] Show Morphs halos from object explorer

[Nicolás Papagna Maldonado]

Aloha folks,

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).

Of course, as Mariano mentioned, an alternative design and solution for
that is another story.
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.

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).
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.

This in particular happened to me when I wanted to change the object that
does highlighting on Smalltalk code.
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.

My two cents.

Cheers,
Nico PM


On Tue, Jun 29, 2021 at 12:19 PM Juan Vuletich via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> On 6/29/2021 11:58 AM, Mariano Montone via Cuis-dev wrote:
> > El 29/6/21 a las 11:54, Juan Vuletich via Cuis-dev escribió:
> >>> Even better than that would be to let the current selected model
> >>> participate in the building of the explorer menu, but I guess that
> would
> >>> be another story.
> >> Yes. That is a good idea. I guess that Object could answer #() to
> >> something like #inspectorMenuOptions, and each class could add its own.
> >> This should be used both for inspectors and explorers, and integrated in
> >> #fieldListMenu , including what currently is at
> >> #addItemsFromDictionaries: , #suggestObjectSpecificMenuItemsFor: , etc.
> > Yeah. Perhaps less intrusive could be to implement using #respondsTo:,
> > so that Object protocol doesn't need to be touched.
> >
> > Like this:
> >
> > (model respondsTo: #someMenuBuilder:) ifTrue: [
> >       model someMenuBuilder: myMenu].
> >
> > Cheers,
> >
> > Mariano
>
> I prefer to avoid calling things like #respondsTo: or #isKindOf: if
> possible. I think in this case, like #inspectorClass, adding to Object
> is reasonable.
>
> Cheers,
>
> --
> Juan Vuletich
> www.cuis-smalltalk.org
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
> https://github.com/jvuletich
> https://www.linkedin.com/in/juan-vuletich-75611b3
> @JuanVuletich
>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>


-- 

Nicolás Papagna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20210629/e9f8b39c/attachment.htm>