About iconNamed:

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

About iconNamed:

stepharo
  hi marcus

Since you raise a problem related about iconNamed: My goal is to factor
all the logic in a couple of root (Model/composableModel) instead of
having is scattered in hundred of places. We cannot work with global
access everywhere. I discussed about it with Guille and Pavel and for
now I should finish and after we think.

I think that object that are displayed in lists, trees should not be
just inheriting from Object.

Check it why people extend core classes to display information in list
of browser.

What should be done is a wrapper object that contains all the ui
information but people are lazy.

For Class and Method that are meta objects we could have one

     DisplayableClass

     DisplayableMethod

that can be used in all the tools and a nice layer.

But we prefer to extend core language meta objects with icons and other
UI things. And after you complain because there is iconNamed: on
ClassDescription but you should think that having a direct reference to
the class Icon is not good either. So the problem is not at the level
you see it.

I do not think that

     #aSymbol asIcon is fixing anything. This is and stay a bad
dependency. The Icon named: or #aSymbol asIcon is just putting the dust

under the carpet. But the reality is still to have a crappy dependency.

Stef