MAPluggableAccessor and block equality

Hi,

I'm toying around with MAPluggableAccessor. While I really like
to introduce some kind of delegated descriptions it doesn't
work that easy. I'm not really familiar with caching of the
magritte descriptions. My problem is that I'm operating on
a MAContainerComponent using childAt: . The children are
detected by =. The MAPluggableAccessor implements equality based
on the equality of the read and write accessors. But these are
blocks and return false if compared.

So I'm wondering what is the intended of the class. I can get
it to work if I'm caching the accessor inside the component.
But maybe it is supposed to work different.

Norbert

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

> I'm toying around with MAPluggableAccessor. While I really like
> to introduce some kind of delegated descriptions it doesn't
> work that easy. I'm not really familiar with caching of the
> magritte descriptions. My problem is that I'm operating on
> a MAContainerComponent using childAt: .

I don't have such a method.

> The children are
> detected by =. The MAPluggableAccessor implements equality based
> on the equality of the read and write accessors. But these are
> blocks and return false if compared.

Indeed, identity of descriptions is currently established with the accessors.

The whole identity thing is problematic and caused some lengthy
discussion dating back to ESUG 2006 in Brussels. At the time I started
with Magritte the accessor seemed to be a decent choice, however later
it became clear that it does not work well for accessors like the
MAPluggableAccessor or MANullAccessor.

Today I think the identity should be established using a special
object, by default it would just use the identity of the description.
If the developer provided an UUID in the code it would use that
instead. Although such an approach does not sound very OO, it is
probably the only way to ensure object identity even if the
description changes completely (including the accessor and the class)
or when identity has to be preserved across multiple images.

> So I'm wondering what is the intended of the class. I can get
> it to work if I'm caching the accessor inside the component.
> But maybe it is supposed to work different.

I don't understand the above part.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

On Fri, 2009-06-26 at 11:27 +0200, Lukas Renggli wrote:
> > I'm toying around with MAPluggableAccessor. While I really like
> > to introduce some kind of delegated descriptions it doesn't
> > work that easy. I'm not really familiar with caching of the
> > magritte descriptions. My problem is that I'm operating on
> > a MAContainerComponent using childAt: .
>
> I don't have such a method.
>
Really? If this since ages and it seems to be your code :)

MAContainerComponent>>childAt: aDescription
   ^ children at: aDescription ifAbsent: [ nil ]

I'm using gemstone but I had this method in my old squeak installation
as well.
I was just wondering if I try to use the MAPluggableAccessor the
wrong way and hence facing problems. I can do

accessor
   ^ accessor ifNil: [
      accessor := (MAPluggableAccessor
         read: [:model|]
         write: [:model :object| ]) ]

and then

descriptionThings
   ^ MAToManyRelationDescription
      accessor: self accessor
      label: 'Things'
      priority: 10

This way I get it running but I don't like it much. I don't know exactly
what MANamedBuilder is caching. I just thought it might solve the
problem by caching the instances.

Norbert

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Ahh, I thought you refereed to MAContainerDescription. I have
#childAt: in MAContainerComponent too.

What you could try is to replace the Dictionary with an
IdentityDictionary in #buildChildren of MAContainerComponent. I am not
quite sure about all the consequences, but I guess it should solve
your problem.

Why don't quite understand what you are trying to do? If you don't use
the accessor just don't assign one.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

On Fri, 2009-06-26 at 12:52 +0200, Lukas Renggli wrote: Ok, I test it at least.
I must be more careful about how to do example code :) At the end the
blocks are of course not empty. Storing the accessor in an instance
variable gives me the identical accessor object with identical blocks.
This way the childAt: call succeeds.

The whole problem deals with tags. Until now I had several objects that
should be taggable. But as the code grew there were other things those
objects could have: comments, scores, etc.

Trying to solve this by inheritance is not possible for me. My idea now
is to treat tags more as meta data: The objects don't contain the data
anymore. At the moment I have any taggable object WHChallenge to that
I add

WHChallenge class>>descriptionTags
   ^ WHTag tagsDescription

WHTag class>>tagsDescription
   ^ (MAToManyRelationDescription
      accessor: (MAPluggableAccessor
         read: [:model|self tagsFor: model]
         write: [:model :tags| self storeTags: tags for: model])
      label: 'Tags'
      priority: 40
   )
   classes: {WHTag};
   reference: WHTag description;
   componentClass: WHTagSelectComponent;
   yourself

The WHTag classes holds all the tag instances. If this approach works
out I would try to solve this even more generic so that I can have a
common code base for this meta-data/annotation kind of things. All
other cases for comments, scores etc. should then be fairly easy

Norbert

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki