Stef, all, the post below was written by me, not by Stef as it looks. Due to some funny bug, my email client messed up with headers when I saved unfinished mail to "Drafts" and then come back to it later. Time to change email client.
I'm very sorry for the confusion this caused. Jan On Wed, 2016-06-29 at 11:21 +0100, stepharo wrote: > > > On Tue, Jun 28, 2016 at 8:53 PM, stepharo <steph...@free.fr> wrote: > > When I implemented annotation support I was initially thinking the > > same - let's create an instance of CoolAnnotationClass when the > > code is accepted > > and then one can add arbitrary code to his CoolAnnotationClass. I > > quickly realized this is a (very) bad idea. Or, to be precise, it > > is a bad idea given the > > environment. So I'd be very careful.. > > can you explain your statement? > > Let me try, this is tricky for me as I'm not good at explaining :-) > > The problems pop out when one need to load the code back. If > <coolish: 100> gets parsed and stored in > an annotation container as instance of class Coolish (at compilation > time), this means that you just > introduced a dependency from package of the method which contains the > annotation to the package of > Coolish class. This is not (or rather was not in my case) desirable, > because I need/want to annotate > methods in kernel with annotations for tools. Kernel should not > depend or tools - I believe we agree on > that :-) Note, that this is less of a problem for Java since Java > loads all code lazily, on demand and in a defined > way. I personally found it very nice - though it has some > (solvable?) issues when this lazy loading is used in Smalltalkish > environment such as STX:LIBJAVA) > > You can indeed parse them and store them as raw data and convert them > on demand in reflective > API. Then, if the class is not available what to do? Return an > instance of generic Pragma? > Throw an error? When one starts to put an arbitrary code into the > annotation object itself it's either > processing code only access data or it somehow fiddles about the > annotation itself and/or (worse!) > about the method itself. The latter results in difficult to debug > problems as the time the code is executed > is undefined (if you use lazy instantiation to avoid dependency > problem). This may be fine with > most Smalltalkers as there are other pieces of code that execute > randomly in an undefined order and still > very few complain :-) but I did not want to make things even worse. > For the former, mere data-accessing processing code, I don't see much > of a difference by putting it > somwhere else. Follows the same logic as visitor, instead of putting > code to nodes, you put them > to extra visitor class. > > Eliot's design elegantly avoid these problems (the same way Java does > :-) by simply having one defined > structure which keeps the logical type of the annotation as data (the > selector of the message send). > It has other problems, but not the one above. > > Not sure if it makes sense, but I did my best :-) I'm not saying it's > not solvable and you cannot have > class per annotation type, but it is not **that** easy to get it > right. This is my experience over the years. > > HTH, Jan > > > > > Stef > > > > > > > > Jan > > > > P.S.: As for "which always forced me to hate Java": I found myself > > a very enlightening to think carefully about why somebody else > > do things differently before I start to hate her/him. Besides, > > there's whole lot of things that Java guys got right... > > > > > >
