[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Re: [zzdev] Errors and exceptions
- To: "B. Fallenstein" <b.fallenstein@xxxxxx>
- Subject: Re: [zzdev] Re: [zzdev] Errors and exceptions
- From: Tuomas Lukka <lukka@xxxxxxxxxx>
- Date: Sun, 15 Apr 2001 01:40:47 +0300
- Cc: zzdev@xxxxxxxxxx
- In-reply-to: <3AD8C8AD.D1799A28@xxxxxx>; from b.fallenstein@xxxxxx on Sun, Apr 15, 2001 at 12:01:18AM +0200
- Mail-followup-to: "B. Fallenstein" <b.fallenstein@xxxxxx>, zzdev@xxxxxxxxxx
- References: <20010414155732.A24224@xxxxxxxxxxxxxx> <3AD875D5.9D9BA6C1@xxxxxx> <20010414193421.B24224@xxxxxxxxxxxxxx> <3AD89A92.561C3713@xxxxxx> <20010414230257.C24224@xxxxxxxxxxxxxx> <3AD8C8AD.D1799A28@xxxxxx>
>
> 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...
Tuomas