Alternative to using a huge map for translations about tower

[ptaoussanis]

Hi there! Sure, new ideas always welcome :-)

Okay, so let me check first that I've understood your motivation correctly (please correct any misunderstandings):

• You want to define a single dictionary by merging small parts so that each small part is relatively easier to manage.
• You want to be able to define parts in different namespaces.
• You don't want to import dictionary parts from external resources (as per the :ja in the `example-tconfig).
• You want to define individual translation entries with a function.

On your implementation:

• There's a recursive merge fn already available in one of Tower's dependencies which you may find convenient:

(:require [taoensso.encore :as encore])
(encore/merge-deep m1 m2 ...)

• You might also find encore/swap-in! useful as a substitute for add-translation!.
• The watch shouldn't be necessary in dev-mode, at least with Tower 2.1. All t fns will automatically recompile any dictionary changes. This may not be true of earlier versions, I don't recall off-hand.

On the general idea:

I don't think there's anything fundamentally wrong with the approach if you're comfortable with it. I may suggest avoiding the per-entry add-translation fn though. Regular maps are portable, translator friendly, and amenable to inspection with the standard seq API when debugging, etc.

I might suggest a middle ground by defining, say, a ns-level map of however-many translations, and then doing a swap-in! merge-deep for the whole lot at once. That way you've still got the benefit of working with plain data, but you can keep it & merge it wherever you find most convenient.

One sharp edge to be aware of: when you're in production, you'll need to make sure that all your dictionary modifiers have executed before the first call to any t fn. The first call will cache the dictionary's value forever. Does that make sense?

[Frozenlock]

It does, thank vou very much!

Oh, and good catch on the merge-deep function!

On Thu, Apr 3, 2014 at 7:09 AM, Peter Taoussanis
[email protected]:

Hi there! Sure, new ideas always welcome :-)

Okay, so let me check first that I've understood your motivation correctly
(please correct any misunderstandings):

• You want to define a single dictionary by merging small parts so
  that each small part is relatively easier to manage.
• You want to be able to define parts in different namespaces.
• You don't want to import dictionary parts from external resources
  (as per the :ja in the `example-tconfig).
• You want to define individual translation entries with a function.

On your implementation:

• There's a recursive merge fn already available in one of Tower's
  dependencies which you may find convenient:

(:require [taoensso.encore :as encore])(encore/merge-deep m1 m2 ...)

• You might also find encore/swap-in! useful as a substitute for
  add-translation!.
• The watch shouldn't be necessary in dev-mode, at least with Tower
  2.1. All t fns will automatically recompile any dictionary changes.
  This may not be true of earlier versions, I don't recall off-hand.

On the general idea:

I don't think there's anything fundamentally wrong with the approach if
you're comfortable with it. I may suggest avoiding the per-entry
add-translation fn though. Regular maps are portable, translator
friendly, and amenable to inspection with the standard seq API when
debugging, etc.

I might suggest a middle ground by defining, say, a ns-level map of
however-many translations, and then doing a swap-in! merge-deep for the
whole lot at once. That way you've still got the benefit of working with
plain data, but you can keep it & merge it wherever you find most
convenient.

One sharp edge to be aware of: when you're in production, you'll need to
make sure that all your dictionary modifiers have executed before the
first call to any t fn. The first call will cache the dictionary's value
forever. Does that make sense?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/41#issuecomment-39438949
.

[Frozenlock]

Why are the given dictionaries paths loaded with io/resource?

With a simple slurp I could load the EDN file wherever it is. But by using io/resource, I need to place my files in the resources directory.

[ptaoussanis]

Resources are more flexible: they're packaged up with your application and can be accessed via the application jar without a concrete file being present and w/o needing to manually distribute your slurps.