Re: Complexity of new hardware

Monday, April 20, 2009, 8:45:23 PM, Adrian wrote:
> To give you an idea, we have over 60,000 lines of reflection definitions in
> our codebase and most of it is stuff I don't want to see when I'm reading
> the header for a class.

Then we have to agree to disagree. I want to know everything about a
member when I see its declaration. You obviously don't. Well, I
wouldn't want to either, if it was that verbose. It really would
clutter the header. But I argue that we can pull all the meta info
needed in a very light-to-read way. I don't think it is the info
itself that creates the verboseness. It is the requirement to have the
problem solved by the compiler. The trick is that this is orthogonal
to portability, and you don't need the compiler at that stage.

> A lot of it has to do with user interface design and telling the
> cinema system which properties can be animated in what ways.

Similar stuff here. UI-specific info, network-specific info, hints on
how to behave on clipboard operations, per-class non-member info, any
additional custom info etc. We also use the system to define
meta-functions that can be called on a generic object, bindings for
scripting, bindings to global variables (cvars), global functions (for
scripting), etc.

And it is all very terse. Because we feel we need terseness to be
quick and more error-proof (re once-and-only-once) when writing new
code. I understand you don't care about that as much.

> There is also stuff that doesn't tie directly to an actual member of
> a class, like a fake "field" that reads data in an old format and
> writes nothing--performing automatic version upgrade during
> serialization.

Isn't that unnecessary? With proper format version tracking, you can
delete and add members to a class without keeping the old members as
clutter (in 99% most cases).

> It is perfectly valid to let a variable name in C++ diverge from the
> string name in the reflection field.

We support that as an option, but it gets a bit awkward, and prone to
search-replace errors. I prefer the number + name + "editor name"
better.

JM2C,
Alen


------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
GDAlgorithms-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list