[Ann] Class meta annotations

I would not use meta because you would not write annotationAnnotations :)

and annotations is meta by its name.

classAnnotation is much better than metaAnnotation 

Denis Kudriashov wrote
> I also realized that this library automatically adds annotations to
> packages because we are now able annotate manifest classes

This all sounds very cool, but would you mind explaining the motivation a
bit? For example, isn't a manifest class itself meta-information about a
package? What does this new feature enable us to do for/with classes and
packages that we couldn't do before? Thanks!

-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Denis Kudriashov wrote
> I thought I explained it in my blog... But I know that I am a bad writer.

Ah, sorry I forgot to re-read the blog and was trying to refresh my
understanding just based on this thread. I wouldn't say the post was poorly
written, just seemed to assume a prior familiarity with the inherent value
of class annotations.

From what I understand, what you're describing sounds very Magritte-like.

What I don't understand is the difference between, for example:

    CmdCommand class>>#activators ^ self classAnnotations select: [ :each |
each isKindOf: CmdCommandActivationStrategy ]

and a <commandActivationStrategy> pragma which signifies a message returning
an appropriate object.

-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

I'd even call them First class pragmas from that point of view :P

I wonder what are the side-effects of instantiating the annotation yourself in a method.

specialAnnotationExample

    <classAnnotation>

    ^MySpecialAnnotation new

I mean, I understand we can use the class state to initialize the annotation. But the fact that the annotation is cached after its first instantiation means that the annotation will not necessarily evolve as the class evolves.

Do we want annotations to be stateless? Or depend only in literals?

I wonder then what is the main difference with

specialAnnotationExample

    <classAnnotation: MySpecialAnnotation>

And what is the impact of having an annotation with parameters.

On Tue, Oct 3, 2017 at 9:02 PM, Sean P. DeNigris <[hidden email]> wrote:

Denis Kudriashov wrote
> If you will use method pragma then you will repeat logic of this library:
> In your code you will need...

So it sounds like it's pragmas++ - the functionality of pragmas plus some
other stuff you may need that you'd have to roll on your own



-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

--

Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - http://www.cnrs.fr Web: http://guillep.github.io Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

Denis Kudriashov wrote

> Generally it is same like having pragma with parameters.
> But with annotation you are not restricted by literal objects. So
> annotation parameters can be anything.
>
> And it is important feature for Commander.
> For example I need instance of KMKeyCombination to define shortcut for
> command. So I just use normal expression for this:
>
> RenamePackageCommand class>>packageBrowserShortcutActivation
> <classAnnotation>

> ^CmdShortcutCommandActivation by: *$r meta* for: ClyPackageBrowserContext
>
>
> It will be very complicated to express it with method pragma and it will
> be
> restricted anyway.

Would it?
With pure method tags, you'd do something like:
SomeClass >> #renamePackage: aPackage
<command: 'Rename package'
 category: 'Package'
 order: 25
 shortcut: #($r meta)>
... method renaming package here ...  

Then have different pragma traversers capable of creating the actual menus /
commands invoking such methods.

(And yes, all caching/invalidation would be the responsibility of the
traverser(s) if necessary, as usual) 

Cheers,
Henry

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

2017-10-04 9:48 GMT+02:00 Guillermo Polito <[hidden email]>:

I'd even call them First class pragmas from that point of view :P

Yes.

But we decided avoid pragma related names here. Because in future it can be possible to add normal pragmas into the class definition.

 

I wonder what are the side-effects of instantiating the annotation yourself in a method.

specialAnnotationExample

    <classAnnotation>

    ^MySpecialAnnotation new

I not understand the question. You supposed to return an instance of the annotation from the "annotating method".

 

I mean, I understand we can use the class state to initialize the annotation. But the fact that the annotation is cached after its first instantiation means that the annotation will not necessarily evolve as the class evolves.

Cache is updated after related class changes: method added, removed and so on (driven by PragmaCollector logic). So outdated annotations should not exist.

Is it what you ask?

 

Do we want annotations to be stateless? Or depend only in literals?

I want annotations to be any object with any state inside. Of course you will be restricted by what is visible from the class side. But in "annotating method" you can create any complex object (see below).

I wonder then what is the main difference with

specialAnnotationExample

    <classAnnotation: MySpecialAnnotation>

And what is the impact of having an annotation with parameters.

Generally it is same like having pragma with parameters. 

But with annotation you are not restricted by literal objects. So annotation parameters can be anything.

And it is important feature for Commander. 

For example I need instance of KMKeyCombination to define shortcut for command. So I just use normal expression for this:

RenamePackageCommand class>>packageBrowserShortcutActivation

<classAnnotation> 

^CmdShortcutCommandActivation by: $r meta for: ClyPackageBrowserContext

 

It will be very complicated to express it with method pragma and it will be restricted anyway.

Another important point is that class annotation is first class object which means that you can add behaviour to it.

With method pragma you can not.

For example shortcut annotation includes method to check given key event and execute command if it is satisfied.

Is it now clear?

On Tue, Oct 3, 2017 at 9:02 PM, Sean P. DeNigris <[hidden email]> wrote:

Denis Kudriashov wrote
> If you will use method pragma then you will repeat logic of this library:
> In your code you will need...

So it sounds like it's pragmas++ - the functionality of pragmas plus some
other stuff you may need that you'd have to roll on your own



-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

--

Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - http://www.cnrs.fr Web: http://guillep.github.io Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

Denis Kudriashov wrote

>> Would it?
>> With pure method tags, you'd do something like:
>> SomeClass >> #renamePackage: aPackage
>>
> <command: 'Rename package'
>>
>   category: 'Package'
>>  order: 25
>>  shortcut: #($r meta)>
>> ... method renaming package here ...
>
> Then have different pragma traversers capable of creating the actual menus
> /
>> commands invoking such methods.
>>
>
> So instead of simple subclassing of ClassAnnotation you would suggest me
> to
> implement pragma traversal/interpreter?
> I would prefer first. It gives me for free the object with any structure
> without any tricky literal interpretation logic.
> For me annotation is just obviously simpler solution.

A traverser doesn't have to be a lot of work;
http://forum.world.st/Having-comments-for-pragma-tp4902987p4903058.html

Denis Kudriashov wrote
> Also try to think how to support blocks in parameters with pragma
> approach.
> And how fun would be to debug them.
>  It is for the question about
> "restricted anyway".

You wouldn't need them. What to do with the tag, is up to the traverser.
For instance, #perform'ing one of the literal args on the domain class
traverser creates, returning an appropriate block, if strictly necessary.

Denis Kudriashov wrote
>  Really, with annotations you have normal smalltalk
> code for annotating classes. No magic. And implementation is really
> simple.

Same with a traverser; the normal smalltalk code to create your domain
objects  is simply in a different place; the traverser part of the package
defining said domain, rather than as an extension method marked with a tag.

I guess it's best to just agree to disagree, and since you're the one
implementing... ;)

Looking forward to trying it out!

Cheers,
Henry



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

 

I mean, I understand we can use the class state to initialize the annotation. But the fact that the annotation is cached after its first instantiation means that the annotation will not necessarily evolve as the class evolves.

Cache is updated after related class changes: method added, removed and so on (driven by PragmaCollector logic). So outdated annotations should not exist.

Is it what you ask?

Nope, imagine you do

RenamePackageCommand class>>packageBrowserShortcutActivation

<classAnnotation> 

^CmdShortcutCommandActivation by: $r meta for: someInstVarOfMyClass

 

If your someInstVarOfMyClass changes its value after the creation of the Annotation object, you're dead.

 

Do we want annotations to be stateless? Or depend only in literals?

I want annotations to be any object with any state inside. Of course you will be restricted by what is visible from the class side. But in "annotating method" you can create any complex object (see below).

I wonder then what is the main difference with

specialAnnotationExample

    <classAnnotation: MySpecialAnnotation>

And what is the impact of having an annotation with parameters.

Generally it is same like having pragma with parameters. 

But with annotation you are not restricted by literal objects. So annotation parameters can be anything.

And it is important feature for Commander. 

For example I need instance of KMKeyCombination to define shortcut for command. So I just use normal expression for this:

RenamePackageCommand class>>packageBrowserShortcutActivation

<classAnnotation> 

^CmdShortcutCommandActivation by: $r meta for: ClyPackageBrowserContext

 

It will be very complicated to express it with method pragma and it will be restricted anyway.

Another important point is that class annotation is first class object which means that you can add behaviour to it.

Yes, I get that and I like the idea that the Annotation is not just a command pattern with an execute method. It can be more than that and that's the interesting part of it. Otherwise a normal pragma can just replace it.

 

With method pragma you can not.

For example shortcut annotation includes method to check given key event and execute command if it is satisfied.

Is it now clear?

On Tue, Oct 3, 2017 at 9:02 PM, Sean P. DeNigris <[hidden email]> wrote:

Denis Kudriashov wrote
> If you will use method pragma then you will repeat logic of this library:
> In your code you will need...

So it sounds like it's pragmas++ - the functionality of pragmas plus some
other stuff you may need that you'd have to roll on your own



-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

--

Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - http://www.cnrs.fr Web: http://guillep.github.io Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

--

Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - http://www.cnrs.fr Web: http://guillep.github.io Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13