Smalltalk › Frameworks & Tools › Magritte, Pier and Related Tools

Understanding the benefits of instance side descriptions.

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Nick

Understanding the benefits of instance side descriptions.

Hi,

In Lukas's proposal for moving to instance-side descriptions there are various benefits mentioned such as:

- Move descriptions from class-side to instance-side. This resolves
various issues such as cache-invalidation, instance specific
descriptions, dynamic descriptions, context dependent descriptions,
etc. Furthermore the descriptions will be closer to the code they
describe and it will be possible to describe class- and instance-side
of an object, not just the instance-side.

I'm not sure I understand the cache-invalidation issue. MAPragmaBuilder is derived from MADescriptionBuilder and uses MADescriptionBuilder cache instance variable which is invalidated in the same way as before, so currently the two implementations are equivalent. Was something different envisaged?

Did you envisage any change to the use of #magritteDynamicObject?

Cheers

Nick

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

Lukas Renggli

Re: Understanding the benefits of instance side descriptions.

Hi Nick,

Not sure if I understand you question, let me know if I answer
something you didn't want to know :-)

> I'm not sure I understand the cache-invalidation issue. MAPragmaBuilder is
> derived from MADescriptionBuilder and uses MADescriptionBuilder cache
> instance variable which is invalidated in the same way as before, so
> currently the two implementations are equivalent. Was something different
> envisaged?

Some Magritte users are unnecessarily rigid, because the descriptions
are only created once and in a meaningless context (on the class
side). This caused some ugly hacks like #magritteDynamicObject or
overrides of #description that should no longer be necessary.

Of course that means we need to drop the global caching, because
Magritte cannot easily decide anymore if a description changes or not.
I don't think this will be a big performance problem, because
descriptions are essentially just data holders for a bunch of
literals. What we could want to cache instead are the selectors that
build the descriptions for a particular class, so that we do not
repeatedly need to walk over the methods of the class hierarchies. And
the flushing would happen as before.

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

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

Yanni Chiu

Re: Understanding the benefits of instance side descriptions.

On 17/01/12 1:34 PM, Lukas Renggli wrote:
>
> Some Magritte users are unnecessarily rigid, because the descriptions
> are only created once and in a meaningless context (on the class
> side). This caused some ugly hacks like #magritteDynamicObject or
> overrides of #description that should no longer be necessary.

Yes, that's the motivation. I needed a magritte description that was
used to populate a select list. The options needed to be based on the
instance's containing object. There's no way for a class-based
description to handle this situation.

Even #magritteDynamicObject was not sufficient because the dynamic block
has no access to the instance.

I'll try out the new code, once I get past my current build problems.

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

Nick

Re: Understanding the benefits of instance side descriptions.

In reply to this post by Lukas Renggli

Hi Lukas

Some Magritte users are unnecessarily rigid, because the descriptions
are only created once and in a meaningless context (on the class
side). This caused some ugly hacks like #magritteDynamicObject or
overrides of #description that should no longer be necessary.

Of course that means we need to drop the global caching, because
Magritte cannot easily decide anymore if a description changes or not.
I don't think this will be a big performance problem, because
descriptions are essentially just data holders for a bunch of
literals. What we could want to cache instead are the selectors that
build the descriptions for a particular class, so that we do not
repeatedly need to walk over the methods of the class hierarchies. And
the flushing would happen as before.

That's clear, I'll drop the caching so the descriptions are created on-demand. However I'm confused as to why the caching couldn't have been dropped before for the class-side descriptions. I realise removing the caching before wouldn't have solved all the problems that instance descriptions have, but it would have removed the need for #magritteDynamicObject and friends. Though perhaps that is only a marginal benefit. Am I missing something?

Nick

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