Hi,
I would like to describe some additional behavior for objects when they are
interacting with another objects.
The prime example is GTInspector; by default to add presentation you
implement a method with "gtInspectorPresentationOrder:". This is fine if
there is just one method like this, but w
Also the problem with visitor here is that I would need X number of
visitors for each method (GtInspectorVisitor, DisplayBlockVisitor, ...) not
to mention that I would need to have the implementation split among
multiple packages, so it is effectively NxM visitors.
Peter
On Thu, Jun 18, 2015 at 7
Hi Peter,
I am not sure I understand.
Is the worry caused by the fact that when there are multiple gtInspector*
methods then the API would get polluted?
Cheers,
Doru
On Thu, Jun 18, 2015 at 7:35 AM, Peter Uhnák wrote:
> Also the problem with visitor here is that I would need X number of
> v
The worry is caused by the fact that I do not want to pollute the protocol;
this is not just about GTInspector, but also about other classes such as
the TreeModel.
So, imagine following hierarchy; there are some "base" classes and then
unlimited number of packages, each with their own hierarchy.
And of couirse FsmIconVisitor is not enough, because TreeModel (menu) might
need different icons than someone else
So, perhaps the question boils down to:
"How to add meta-description to object from another package without
affecting the object's protocol or code?"
For example Roassal's
2015-06-18 7:23 GMT+02:00 Peter Uhnák :
> Hi,
>
> I would like to describe some additional behavior for objects when they
> are interacting with another objects.
>
> The prime example is GTInspector; by default to add presentation you
> implement a method with "gtInspectorPresentationOrder:". This
I think what Peter means is: the object oriented way to handle different types
is by dispatching on each type (~ double dispatch, ~ visiting). You could need
this for different aspects of your application. In the end, the same core
mechanism will be implemented multiple times. Sadly, minor seman
>
>
> > I don't fully understand the TreeModel example, what would your tool do
> with all the men/displayBlock/childrenBlock ... - methods?
>
Ah, I should've explained what TreeModel is; it is a Spec UI widget to
display tree-like structures:
So the way this works is that I give the TreeMod
And gmail didn't add the image correctly it seems...
On Thu, Jun 18, 2015 at 10:10 AM, Peter Uhnák wrote:
>
>> > I don't fully understand the TreeModel example, what would your tool do
>> with all the men/displayBlock/childrenBlock ... - methods?
>>
>
>
> Ah, I should've explained what TreeM
2015-06-18 8:37 GMT+02:00 Peter Uhnák :
> The worry is caused by the fact that I do not want to pollute the
> protocol; this is not just about GTInspector, but also about other classes
> such as the TreeModel.
>
> So, imagine following hierarchy; there are some "base" classes and then
> unlimited
Why not try to use TreeNodeModel to define different kind of nodes? On each
node you can redefine the way to get children, the icon, etc.
Then you give these nodes as the tree roots.
Le 18 juin 2015 à 10:10, Peter Uhnák a écrit :
>
> > I don't fully understand the TreeModel example, what would
childrenFor: anObject
| col name |
^ApplicationTreeModelAdapter sharedInstance childrenFor: anObject
ApplicationTreeModelAdapter>>childrenFor: anObject
^mapping at: anObject
ApplicationTreeModelAdapter>>register: aOneParameterBlock at: aClass
mappaing at: aClass put: aOne
Wake up before posting
childrenFor: anObject
| col name |
^ApplicationTreeModelAdapter sharedInstance childrenFor: anObject
ApplicationTreeModelAdapter>>childrenFor: anObject
^mapping at: anObject
ApplicationTreeModelAdapter>>register: aOneParameterBlock at: aClass
mapping at: aClas
Stephan Eggermont writes:
> ApplicationTreeModelAdapter>>childrenFor: anObject
> ^mapping at: anObject
>
> ApplicationTreeModelAdapter>>childrenFor: anObject
> ^(mapping at: anObject class) value: anObject
the same method with 2 different behaviors.
--
Damien Cassou
http://damiencas
On 18-06-15 13:35, Damien Cassou wrote:
Stephan Eggermont writes:
ApplicationTreeModelAdapter>>childrenFor: anObject
^mapping at: anObject
ApplicationTreeModelAdapter>>childrenFor: anObject
^(mapping at: anObject class) value: anObject
the same method with 2 different behaviors
This is true, however it has to be used properly.
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> On Jun 18, 2015, at 4:13 AM, Peter Uhnák wrote:
>
> For example Roassal's RTElement expo
16 matches
Mail list logo
