[fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing

[Reinier Olislagers]

On 15-8-2012 10:08, Rainer Stratmann wrote:
> Am Wednesday 15 August 2012 09:59:00 schrieb Lukasz Sokol:
>> On 15/08/2012 08:33, Rainer Stratmann wrote:
>>> Am Wednesday 15 August 2012 03:52:00 schrieb waldo kitty:
>>>> the loading code simply
>>>> chooses the proper po file and then loads the strings into an array or
>>>> whatever using the same variables which are used everywhere no matter
>>>> what language their contents are written in...
>>>
>>> Do you need a separate pascal identifier for each snippet?
>>>
>>>> i must still be missing something :?
>>
>> No with (dx)gettext you don't need pascal identifiers for every string.
>> And the translating function is _():string;
>> So all you do is writeln(_('snippet1'));, to follow your convention.
>>
>> So it more or less uses the same idea as you are trying to replicate.
>>
> Yes, that is possible as I understand it so far.
> I did not know (dx)gettext before so replication is may not the right word.
Yes, it is. Replication is doing the same thing twice, regardless of the
reasons/knowledge behind that fact.

> My solution will be more flexible I assume.
> I put already some hours in it and I like to write my own code so I follow the 
> already driven way.
I haven't used dxgettext, but would ask you to have a serious look at
it. Presumably dxgettext users/developers had many of the same problems
you face and have created solutions for those problems over the years.
I understand you take pride in your own code and it feels like wasted
effort to dump it, but using a set of proven code may be advantageous.

You can still submit your own improvements to dxgettext if you hit
problems... and if those aren't accepted, in the worst case create your
own fork.

You already have a very good grasp of the issues involved as you were
writing your own solution. You could probably improve dxgettext with
some things and get that in the main development tree, thereby improving
things for others.
The other way round also works: other peoples' improvements can end up
in your code for free (almost: you'll need some
implementation/verification time).

While this may all be very well known to you, I would ask you to step
back and consider it: having a detached look at it may lead to a better
choice.

Just my 2 cents,

regards,
Reinier