[e-lang] Patch (0.8.28e): Removing ValueGuard#getName/0
tribble at e-dean.com
Sat Jul 10 21:25:16 EDT 2004
I vaguely recalled some uses that were not printOn, but did not actually
look. I was reacting to the pattern of potentially relying on specifics
of printOn rather than the an actuality. optUncall would have the same
problem: its semantics don't specify a representation, and so it would
only be coincidence that it happened to produce the name of the guard.
But that's all minor background. My more important vague memory is that
optName is a hack, and caller should not be counting on that value,
Kevin Reid wrote:
> On Jul 10, 2004, at 15:56, Dean Tribble wrote:
>> Kevin Reid wrote:
>>> See <http://www.eros-os.org/pipermail/e-lang/2004-April/009807.html>
>>> for context.
>>> This patch removes all occurrences of ValueGuard#getName/0 and
>>> replaces them with the regular printing system (__printOn/1, etc.).
>>> It has not been thoroughly tested.
>> I think that one should not rely on printOn to produce a
>> computer-usable output. Thus, this replacement only makes sense for
>> circumstances in which the value was printed. It does not make sense
>> for the callers that were trying to get a precise value assocaited
>> with the ValueGuard.
> Is getName/0 ever used to get 'a computer-usable output' now? I do not
> recall finding any such usage when I searched the source to produce
> this patch.
> Are there plans to do so in the future?
> Surely __optUncall is a better solution for that purpose, as using a
> string result would require that the caller and the target agree on
> the scope to be used?
> Quoting from
>> Guard#getName/0 should probably go away, and its uses replaced with
>> either __printOn/1 or Data-E serialization, both of which handle cycles.
>> The use which originally motivated it is found in
>> MessageDesc#printDescOn/1, which is used in displaying on-line help.
More information about the e-lang