[Nebula-Discuss] Fwd: '4CCO' (four character codes) versus Symbols

[Mateu B. <mb...@gm...>]

2007/4/3, Vadim Macagon <va...@cu...>:

[snipped]

> That should be http://sharedmind.blogspot.com :)

Ooops ! Thanks enlight. I didn't want to share my Ming at all :D

> You mention that the calculation of symbol ids can be done as a
> pre-compile build step or by the Nebula build system, which way did you
> implement it?

We implement it with the Nebula build system as a new generator type,
which should be more portable but it has the annoyance of having to
redo this process when you add or change a symbol in your code
(although we could do easily that the pre-build step calls this
generator before compiling). We alleviate this problem by having to
rerun this only for the release, and doing a more dynamic runtime
symbol register in debug. By the way, I forgot to say we allow
insertion of new symbols in runtime.

> This sounds interesting, but since it's a change to the core we're going
> to have to figure out how to proceed. I'm going to write up some options
> this evening.

Yeah, I know. In my opinion I'd not change the core at all, it is not
worth, less if we think that Nebula 3 is near. I have had just bad
experiences so far by modifying the core, for example the change to
nObject (which IIRC Bruce and Enlight did) and the signal system (done
by Bruce and me). Even that both changes have been very useful and
worth for us. But what I mean is changing apart from Radon Labs is
like signing a death penalty for those features, or worse creating a
branch off the main project.

I like this feature and I was aiming that this or something similar is
considered for Nebula 3 core, which seems to be not so far away (so
maybe it is too late for that). I just wanted to catch the attention
of floh, I did a post in his blog about this. And he did an
interesting reply:

Floh said...:

"Hmm, this seems to be similar to our "Attribute Id's" we have built
for Mangalore and which will be integrated in Nebula3 (and heavily
used). Attribute Id's are unified string/fourcc/C++-symbol
identifiers. When using them in C++ code, you use the C++ symbol (and
get a compile error if the attribute id doesn't exist), but you can
also get the associated string or fourcc code, which is useful for
persistency or communication (since the symbol form is basically a
pointer to a static C++ object which doesn't make sence across
processes). Attribute Id's are also associated with a datatype (like
Int, Float, etc...), and using a mismatching datatype with the
attribute id also results in a compile error. I think one of my next
blog posts will be about attributes ;)"

I've taken a look at this, and I've some comments:

In my opinion, the attribute ids just share some of the functionality
with the symbols, but attribute ids are a much higher level than
symbols. The attribute ids could be implemented on top of the symbol
system. Attribute ids come with extra functionality which limits the
general applicability of symbols. The symbol system just provides one
thing, a constant string, that can be used in many places.

Attribute types can be checked for existence in compile time. This
seems good a priori, and probably it is the proper thing with
attributes. But this means that attribute ids must be declared and
registered explicitly, symbols are aimed to be very simple to use
because we thought that if they're more complicated than necessary
programmers will not use them. That's why the programmer has just to
write NS(symbol) to use a symbol, that's all, and that's why we have
written a build system generator to do all the "register" process
behind the scenes (we wanted a compile-time solution not runtime). And
it would be much simpler if C++ already had symbols meant to be used
by the programmer, many other languages have them. Back to the main
theme, comparing symbols and attributes (just in the symbol
functionality), I think attributes are not that easy to use, you have
to define them, register them, and the fourccs are still really there
so all problems defined before are still there as well.

BTW, I forgot one more example of the applicability of symbols. For
those enums that have to be converted from and back to string (there
are many of those in Nebula). Symbols already provide that
functionality, so these functions are not needed anymore.

cheers
  Mateu