First let me say, Magritte is great, and works well. But like all software
systems, there is an opportunity for improvement.
We have added several of our own renderers, and so I have encountered some
difficulties myself. And again, praise for Magritte because it does, in
many places throughout the code, provide mechanisms for overriding default
classes and behaviors. I like that the properties dict is readily
accessible make it far more extensible than it would be without it. There
is a LOT to like!
What Udo describes is a common problem when it comes to re-using libraries:
the ability to substitute in your objects... is not always easy. This is
not a Magritte-only issue, in fact, Magritte was prepared for this better
than most classes I encounter. Over the years, I have encountered many
libraries that require strict adherence to the class hierarchies provided
within. And in many cases of using these libraries, one writes way too much
code mapping between object types, and/or subclassing everything. (If my
class satisfies the interface, why can't I substitute it for the native
class? -- rhetorical, as there are always exceptions.)
Generally speaking, I believe we should rely less on rigid inheritance than
on our ability to send any message to any object. This extreme polymorphism
provided by Smalltalk is what makes so great. If we are going to require
and design with strict inheritance requirements, we might as well be
working in languages that support multiple inheritance.
Another catch, that is also a general problem in OO
programming/code-organization: just because the programmer of a library
defined a MagritteDescription set, doesn't mean she knows how the end
application would want the tool rendered. In fact, a given application may
wish to present the component in many different ways -- mine does.
Therefore I added methods like the following, to help present different
ways in different contexts:
#asTableReportFor: aList magritteDescription: magDescr commandColumns:
And numerous other, and permutations of, such convenience methods.
As noted by Udo: indeed, the weaving in of CSS makes problems like this
even more complex.
One potential solution to the default class substitution problem, is to
give users of libraries a way to specify the substitute classes in one neat
table... but that 'view' of the world should be only one ...
namespace-re-mapping, because, perhaps another piece of code in the same
image (and even subsystem) does not want to make the same substitutions.
[Which means all class refs must be compiled to be a lookup of the class by
name in a thread specific namespace -- rather,
namespace-override-dictionary. ... or something... better thought out!]
I am a big believer in registries. It is crazy to *believe* that in one
location, one programmer can stuff all the information into an object
(instance) that satisfies all the needs of all would-be users of the class;
especially if this information is hard-coded into the class definition
(instance side). Rather, the designer of an application, probably does know
how they want certain things displayed; and when they don't, they use
Again, my comments are very general. I love Magritte, it is a core tool
that I use.
[And if this is all just off-topic silly blather ... please don't flame me!]
On Tue, Aug 20, 2013 at 3:14 PM, Damien Cassou <damien.cassou(a)gmail.com>wrote:
On Tue, Aug 20, 2013 at 4:58 PM, Udo Schneider
> So I'm wondering whether I missed some functionality to plugin custom
> behavior into the hierarchy or whether the provided hierarchies are
> an example which only can be customized to a certain point. Everything
> beyond has to be done "manually".
I'm not sure what you want to achieve but I guess it will be possible
without too much additional code (and without duplicating code). Could
you please tell us in more details what you want as a result?
"Success is the ability to go from one failure to another without
Magritte, Pier and Related Tools ...