[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

Re: [zzdev] Re: [zzdev] Errors and exceptions

> Absolutely agreed. (Do we really need to prefix that it with 'ZZ'?
> 'ClangException' seems to be unique enough. 'InfiniteLoopException'
> should IMO not be prefixed either, because the loop detector is not
> connected to ZZ except that the code was written on this project.)

And the code is part of ZZ. I do prefer having the exceptions clearly
marked as being in our code (as opposed to JVM or JDK).

> I was mixing non-clang related stuff in, though (separating that does
> make sense): strange ZOb/bindings/window cell/etc. system structures
> which are not the way the system expects them to be. I think there
> should be an error encompassing that kind of thing (we might want to
> give a special kind of feedback to the user). Anyway, that would be more
> clear than a NullPointerException (only if you take the time to write a
> meaningful error message instead of letting the NullPointerException
> bubble up, of course, but you should do that). So I think we should have
> an exception for that, too.

Right... MalformedZObException?

> > > I don't think renderables should be there at all. The current interface
> > > for decorations is holding us back. I'm not sure yet how we can improve
> > > on it, but fixing it at this point seems to be totally unreasonable.
> > 
> > Hmm... Renderable is not meant to solve this: Renderable is something
> > that is simply painted at some depth.
> I know; that's why I think we shouldn't keep it. I'm not clearly opposed
> to it, don't get me wrong, I just do not see what we need it for. We can
> always use a vob without a cell the way we use Renderables now, and we
> do not need additional efficiency if we don't do the connections that
> way anyway. Or am I missing something? What is the use for renderables
> you foresee?

Things for which interpolation makes no sense. But true, cell==null
covers that as well. You're right: the distinction is arbitrary. Off they
go ;)

> > Probably something like "Connection" or "VisualConnection".
> Considering the current naming, "Connection2D"?

Hmm. Connection is still not right: it's singular, whereas the thing
can have lots of stuff inside. Connector2D?

> > Yes, maybe connections really do need to be completely outside the
> > current flat-2 1/2 D vob system. That would make sense.
> > 
> > Hmm, we probably should support this in the core APIs - suggestions?
> Why, the core APIs should be more or less frozen; so we should IMO not
> add something there we have *no* experience with so far. It doesn't cost
> us much to move stuff there later. ;o) What about this: I write a first
> experimental implementation sometime next week (hope I'll be able to do
> that), and then we see how it works and what we'd like to change before
> moving it to core.

Sounds very good.

> Something else: Why do the core/ vobs not have anything related to
> interpolation in them?

Simply not yet put in there. 

   abstract public void render(java.awt.Graphics g, 
				int mx, int my, int mw, int mh);

is going to be used, of course.

I'm still thinking about how to do varying LODs correctly: simple and flexible
is difficult there...