>>It's that, in Open-RJ, two of the three enums are error codes. In the
>>C
>>library there's a static array of structs mapping the value to a
>>string.
>>
>>This is a really common idiom, but painfully verbose and also very fragile - it's all too easy to get the Doxygen doc strings out of step with the string literals used in the translation - so I figured that D might address this. I still feel that that's worthwhile. (Note: in C, one can keep it all in the DRY SPOT by using macros, which we, er, cannot do in D. <g>)
>
> If it is so common, then it should be exposed by the compiler via
> reflection.
> That way it would not be fragile, and would stay in that DRY SPOT.

Cool.

>>Of course, this does not address localisation, and I don't suggest it does. It's just a safer shortcut for what we do now anyway.
>>
>>I've been thinking that rather than strings we might also associate
>>string identifiers, which would be hooked into the i18n framework
>>that,
>>as yet, does not exist. ;)
>
> That i18n framework *does* exist. It's called ICU, and it has a slew
> of tools
> for producing, configuring, editing, and managing such resources. The
> best part
> about ICU is the level of maturity, and the vast sums of money poured
> into it by
> IBM et. al.
>
> It may not be ideal, but it's a long way down a reasonable path.

Sorry. I meant like not something in D yet.


>>"kris" <fu@bar.org> wrote in message news:d0ps0h$2fbt$1@digitaldaemon.com...
>>> Hey Andrew;
>>>
>>> I figured Matthew was using these enum-names for a non-i18n
>>> application only ~ once you start getting into locale-specifics,
>>> there's a whole lot more to consider (as I'm sure you know) and the
>>> strings themselves would very likely be externalized in one manner
>>> or
>>> another: making this topic somewhat moot?
>>>
>>> Of course, this is probably now way-off topic; so I'll mention the
>>> ICU
>>> tools/APIs once again (WRT this domain) and then shuttup ...
>>>
>>> - Kris
>
> 

In article <d0qrj5$g81$1@digitaldaemon.com>, Matthew says...
>> If it is so common, then it should be exposed by the compiler via
>> reflection.
>> That way it would not be fragile, and would stay in that DRY SPOT.
>
>Cool.


So how about it? What do folks think about a compiler-option to retain & expose reflection material such as enum-names? It would presumeably be a step along the path of reflection, and probably won't even be seriously considered until after 1.0 ... ?

That would appear to be a neat way of providing tags for externalized content, including i18n considerations.



>> That i18n framework *does* exist. It's called ICU, and it has a slew
>> of tools
>> for producing, configuring, editing, and managing such resources. The
>> best part
>> about ICU is the level of maturity, and the vast sums of money poured
>> into it by
>> IBM et. al.
>>
>> It may not be ideal, but it's a long way down a reasonable path.
>
>Sorry. I meant like not something in D yet.


Not to be argumentative, but it kinda' is available in D; we've got wrappers for almost all of the ICU APIs :-)

Perhaps that's not what you meant ...

"Kris" <Kris_member@pathlink.com> wrote in message news:d0qvv9$k3q$1@digitaldaemon.com...
> In article <d0qrj5$g81$1@digitaldaemon.com>, Matthew says...
>>> If it is so common, then it should be exposed by the compiler via
>>> reflection.
>>> That way it would not be fragile, and would stay in that DRY SPOT.
>>
>>Cool.
>
>
> So how about it? What do folks think about a compiler-option to retain
> & expose
> reflection material such as enum-names? It would presumeably be a step
> along the
> path of reflection, and probably won't even be seriously considered
> until after
> 1.0 ... ?
>
> That would appear to be a neat way of providing tags for externalized
> content,
> including i18n considerations.

I'm certainly keen to here:
    - from the group whether this is desirable
    - from the group whether there might be slight differences from the
way I've expressed it that would be preferable
    - from Walter as to whether this is something that can be readily
incorporated into the language.

>>> That i18n framework *does* exist. It's called ICU, and it has a slew
>>> of tools
>>> for producing, configuring, editing, and managing such resources.
>>> The
>>> best part
>>> about ICU is the level of maturity, and the vast sums of money
>>> poured
>>> into it by
>>> IBM et. al.
>>>
>>> It may not be ideal, but it's a long way down a reasonable path.
>>
>>Sorry. I meant like not something in D yet.
>
>
> Not to be argumentative, but it kinda' is available in D; we've got
> wrappers for
> almost all of the ICU APIs :-)
>
> Perhaps that's not what you meant ...

Kris, I'm largely ignorant of the subject, and, apparently, was purely pontifulating. :-)

In article <d0r2a1$me8$1@digitaldaemon.com>, Matthew says...
>"Kris" <Kris_member@pathlink.com> wrote in message
>>
>> So how about it? What do folks think about a compiler-option to retain
>> & expose
>> reflection material such as enum-names? It would presumeably be a step
>> along the
>> path of reflection, and probably won't even be seriously considered
>> until after
>> 1.0 ... ?
>>
>> That would appear to be a neat way of providing tags for externalized
>> content,
>> including i18n considerations.
>
>I'm certainly keen to here:
>    - from the group whether this is desirable
>    - from the group whether there might be slight differences from the
>way I've expressed it that would be preferable

I'll bite. :)

I think that a full-on reflection system is desireable, but realizing that goal should probably be done as a wholesale design, rather than as a piecemeal set of improvements.  I'd like to see us back something really close to the right design the first time round, rather than have to refactor needlessly as we go.

As for enums, something transparent like

> enum Test{
>    FOO,BAR,GORF
> };
> 
> Test t = FOO;
> char[] name = typeid(Test).getValueName(t);
> char[] name2 = t.typeinfo.getValueName(t); // equivalent

I would like to void *against* any idea for the following c++ boost-ism:

> char[] name = lexical_cast!(char[])(t);

.. we can do better than that.

As for a compiler option, I think that's a moot point.  If someone is going to write code that's "lean and mean", why wouldn't they just write procedural code and leave it at that?  After all, if you don't use any user-defined types, then the only typeinfo instances added to the app are for your scalar and array types.

Classes already present overhead in the form of type information and v-tables already, so the needed metadata to fully support a complete reflection system probably won't bloat things too much.

- EricAnderton at yahoo

In article <d0r2a1$me8$1@digitaldaemon.com>, Matthew says...
>
>
>"Kris" <Kris_member@pathlink.com> wrote in message news:d0qvv9$k3q$1@digitaldaemon.com...
>>
>> So how about it? What do folks think about a compiler-option to retain
>> & expose
>> reflection material such as enum-names? It would presumeably be a step
>> along the
>> path of reflection, and probably won't even be seriously considered
>> until after
>> 1.0 ... ?
>>
>> That would appear to be a neat way of providing tags for externalized
>> content,
>> including i18n considerations.
>
>I'm certainly keen to here:
>    - from the group whether this is desirable
>    - from the group whether there might be slight differences from the
>way I've expressed it that would be preferable
>    - from Walter as to whether this is something that can be readily
>incorporated into the language.

Some reflection is better than no reflection IMO.  And were I to use such a feature, it would have to be built into the compiler or at least supplied with a standard compiler package.

>> Not to be argumentative, but it kinda' is available in D; we've got wrappers for almost all of the ICU APIs :-)
>>
>> Perhaps that's not what you meant ...
>
>Kris, I'm largely ignorant of the subject, and, apparently, was purely pontifulating. :-)

Kris picked up the ball when Jill disappeared and did much of the work himself. It's over at dsource :)


Sean