RE: Nanning UML diagrams

"jon_tirsen" <[email protected]> Wed, 28 May 2003 19:42:50 +0200
Newsgroups gmane.comp.java.nanning.devel
Message-ID <001f01c32540$93883de0$6c4a59d5@jon>
Thanks! I'll add it to some page at http://nanning.snipsnap.org .

Feel free to steal any code you like.

Actually Nanning-objects don't create as much overhead as you'd think.
Initially we just Nanningified service-objects but now we do it to all
domain-objects. Of course there's some overhead.

Next generation Nanning will probably use some kind of byte-code
manipulation technique and will result in much less overhead per object.
But that's not in the very near future (probably after the summer).

-----Original Message-----
From: Piotr Kaminski [mailto:[email protected]] 
Sent: den 26 maj 2003 05:53
To: [email protected]
Subject: Nanning UML diagrams

Hi Jon,

I've taken a look at Nanning today, and while trying to understand its
structure I whipped up some simple UML diagrams of the core pieces.  In
case
you're interested, I've attached the PDF file (I can send you the Visio
file
as well, if you'd like).  Feel free to post this on the snip-snap site,
or
ignore it as you wish.  :-)  I just thought it might save other people
some
time...

Incidentally, I probably won't be using Nanning in my project.  While it
is
fluid, which I need and which disqualifies AspectWerkz (I think?) and
AspectJ, it creates too much object overhead.  I intend to aspectify
every
object in a knowledge representation framework, so, if I understand
Nanning
right, I'd have to create a new AspectInstance for each data element,
with
its attending maps, lists, etc.  To preserve some semblance of
scalability,
I think I'll reuse the attribute compiler but hack my own dispatching
mechanism right into my app.

Nanning is still pretty cool, though!

		-- P.

--
  Piotr Kaminski ([email protected])
  It's the heart afraid of breaking that never learns to dance.
 



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge