[self-interest] have to get this off my heart

Jan-Paul Bultmann janpaulbultmann at me.com
Sun Dec 26 13:12:13 UTC 2010


I didn't say that they are useless :D
But they are one of those black magic things that happen in the VM and don't emerge out of existing concepts a bit like resends. Even though they are implemented nicely through the use of mirrors.
They also create a problem that is best known form  XML, what is property and what is content.
Should a comment go into the method or in to the annotation, why is the storeString stuff not in the annotation as well as prototype information.
They could be purely for meta information like store-strings, comments and categorisation, but then we should put everything that is not necessary for the function of the object into them.
Even though they tend to contradict the principle of simplicity in my opinion, when they are there they should be part of the family and not some distant cousin you don't talk about.
When describing a Object we can no longer say it is composed of slots, and those slots hold information.
We have to say that a Object is composed of slots and Meta information in form of an annotation object, and those slots hold Information and meta information.

So it is not the idea that a Object can hold meta information that I don't like, it is more the fact that we should embrace them as a part of the language we are proud of, (like the totally awesome namespace ;) and cloning ) or we should find a different way.

Cheers Jan
On Dec 26, 2010, at 8:21 AM, ungar at mac.com wrote:

> 
> I put annotations in to support the other world; not the world at execution-time, but the world at programming time.
> I have yet to see a model of execution that supports all of the structure a programmer needs to impose upon the world.
> For instance, if you are going to file out a subset of objects or slots and then file them in to another world of objects, I am convinced
> that you need more information than just what is needed to run the objects. See my OOPSLA transporter paper for details.
> 
> Also, it is very useful to have categories within a single object. At run-time you need just one object, but at concept-time, you need
> some way to group things, although a strict hierarchy may not be optimal.
> 
> So, if you need some information that plays no role in execution, it must only exist in the reflective domain.
> I don't see how you get anything much different than annotations, but I would enjoy seeing proposals.
> 
> Copy-down is a bit of a different matter. It sort of straddles programming time and run time, though only REFLECTIVE run-time.
> Maybe the folks at Vrije have a better way, or maybe Ly, my latest object system design is better. (I think so.)
> In Ly, all non-constant slots are copied-down, as part of the language.
You like names that are not googable, don't you ;D

> 
> It's easy to complain about something, but think about why it's there and how else you would do it.
> In my experience, one ends up sweeping dirt around under the carpet; it doesn't go away. 
> Once in a while there is a nice unification. If you don't like annotations, let's see you find that unification.
> 
> - David
> 
> 
> On Dec 25, 2010, at 10:39 PM, Josh Flowers wrote:
> 
>>  
>> Not sure I'd have been quite so diplomatic about it - but I don't disagree.
>> 
>> > First of all I wish you all the best :D.
>> > 
>> > I hate annotation.
>> > They are like a language in a language.
>> > Why not create invisible slots or something that are simply hidden my the outliner.
>> > C'mon they managed to do the fricking namespaces with objects and slots... why then staple something on top later.
>> > This has kept me up all week, what a relief.
>> > 
>> > Happy Holidays, Jan
>> > 
>> > 
>> > ------------------------------------
>> > 
>> > Yahoo! Groups Links
>> > 
>> > 
>> > 
>> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.selflanguage.org/pipermail/self-interest/attachments/20101226/b69e7c68/attachment.html>


More information about the Self-interest mailing list